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Chapter  1 
Introduction 

1.1  Problem  Statement 

The  Fault-Tolerant  Parallel  Processor  (FTPP)  developed  at  the  Charles  Stark 
Draper  Laboratory  is  a  computer  architecture  aimed  at  achieving  high  throughput  while 
maintaining  a  high  level  of  reliability.  These  are  necessary  qualities  for  a  computing 
system  that  could  be  called  upon  to  perform  flight-critical  and  mission-critical  tasks  such 
as  those  found  in  an  aircraft  flight  control  system.  The  FTPP  utilizes  multiple  processing 
elements  (PEs)  operating  in  parallel  to  achieve  high  throughput,  and  it  maintains  high 
reliability  through  implementation  of  PE  redundancy  and  Byzantine  resilience.  The  high 
throughput  of  the  FTPP  makes  it  an  ideal  host  for  hard-real-time  applications,  and  its 
custom-built  operating  system  uses  a  rate  group  scheduling  paradigm  to  properly 
schedule  iterative  execution  of  real-time  tasks.  Application  tasks  are  divided  into  rate 
groups  according  to  their  required  frequency  of  execution,  and  the  operating  system 
schedules  individual  tasks  for  execution  at  regular,  predefined  intervals.  For  a  real-time 
system,  it  is  critical  that  each  task  complete  its  execution  cycle  within  its  allotted  time 
frame;  an  inability  to  complete  execution  on  time  results  in  a  condition  known  as  a 
performance  failure. 

The  current  incarnation  of  the  FTPP  is  the  Army  Fault  Tolerant  Architecture 
(AFTA).  It  is  designed  to  be  highly  configurable  and  thus  capable  of  supporting  a 
varying  set  of  mission  requirements.  The  AFTA  can  support  as  many  as  forty  individual 
processing  elements,  and  :hese  are  organized  into  a  flexible  set  of  virtual  groups  (VGs)  to 
achieve  PE  redundancy.  For  any  particular  mission,  the  AFTA  is  uploaded  with  a  suite  of 
application  tasks,  each  of  which  may  execute  on  one  or  more  virtual  processing  groups. 
Individual  tasks  vary  according  to  function,  required  level  of  redundancy,  required 
frequency  of  execution,  and  expected  execution  delay.  Given  the  variability  of  the  AFTA 
hardware  and  software  configuration,  one  may  produce  an  overwhelming  set  of  all 
possible  mappings  between  tasks  and  processing  sites.  For  a  hard-real-time  system,  it  is 
critical  for  the  task  workload  to  be  properly  distributed  among  the  virtual  groups  so  that 
all  tasks  are  able  to  complete  their  iterative  execution  cycles  within  their  allotted  time 
frames.  In  order  to  identify  such  a  task  distribution,  one  may  use  a  form  of  operational 
trial  and  error,  but  it  is  certainly  preferable  to  know  in  advance  if  a  chosen  configuration 
of  hardware  and  software  satisfies  necessary  real-time  constraints.  For  that  purpose,  this 
thesis  presents  an  automated  software  tool  to  perform  a  timing  analysis  of  any  given 
system  configuration. 
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1.2  Objective 

The  automated  timing  analysis  takes  into  account  the  full  system  configuration- 
both  hardware  and  software.  It  performs  a  static  analysis  of  the  source  code  for  each 
application  task  and  uses  system  performance  data  to  estimate  a  least  upper  bound  on  task 
execution  time.  The  timing  analysis  relies  heavily  on  source  code  modeling  techniques, 
and  the  limitations  of  modeling  prevent  a  precise  calculation  of  execution  time.  A  worst 
case  scenario  is  considered  in  the  analysis,  and  a  minimum  (rather  than  maximum)  worst 
case  delay  is  defined  using  the  model.  Once  a  least  upper  bound  is  established  for  every 
task,  the  tasks  are  categorized  according  to  their  virtual  group  and  rate  group 
specifications,  and  comprehensive  calculations  are  made  for  each  virtual  group  to 
determine  if  the  overall  system  can  satisfy  real-time  constraints  under  worst  case 
conditions.  This  calculation  is  known  as  the  frame  overrun  check,  and  it  takes  into 
account  the  following:  hardware  configuration,  application  task  characterization,  task 
scheduling  overhead,  and  operating  system  performance  data. 

The  use  of  the  analysis  tool  is  not  valuable  solely  for  the  overrun  prediction; 
rather,  the  overrun  check  is  simply  the  most  comprehensive  result  produced.  The  more 
important  results  are  the  intermediate  values  used  in  performing  the  overrun  check. 
These  include  the  delay  of  the  rate  group  dispatcher  and  the  parameterization s  of  the 
individual  application  tasks.  One  of  the  major  goals  of  this  analysis  is  to  properly 
characterize  the  software  tasks  for  timing  estimation,  code  optimization,  and  for  further 
analysis  of  global  message  traffic  and  virtual  group  phasing  (to  be  accomplished  by  other 
tools).  After  a  single  configuration  analysis,  it  should  be  readily  apparent  what  types  of 
changes  could  be  made  to  the  system  for  better  performance  results.  These  changes 
might  include  streamlining  application  task  code,  altering  the  mapping  between  tasks  and 
virtual  groups,  adjusting  the  virtual  group  configuration  of  the  AFTA  hardware,  or 
switching  the  rate  group  specification  of  one  or  more  application  tasks. 

1.3  Approach 

This  timing  analysis  uses  a  modeling  approach  to  account  for  the  combined 
behavior  of  the  hardware  and  software  in  any  given  system  configuration.  The  analysis 
tool  examines  the  Ada  source  code  for  each  application  task  and  develops  a  model  for  its 
flow  of  execution.  From  this  model,  every  possible  path  of  execution  is  generated  and 
characterized  according  to  a  predefined  set  of  parameters.  Using  performance  data  for 
the  AFTA  operating  system,  the  analysis  tool  compares  the  estimated  execution  times  of 
all  paths  and  thus  identifies  the  worst  case  path.  Once  a  worst  case  path  is  defined  for  all 
application  tasks,  this  data  is  input  to  a  model  of  the  hardware  configuration.  The 


ft 

hardware  model  primarily  accounts  for  the  mapping  between  software  tasks  and 
processing  elements,  and  it  uses  the  worst  case  path  parameterizations  to  determine  if  the 
full  system  can  satisfy  real-time  constraints  under  worst  case  conditions. 

All  the  analysis  functions  described  above  are  performed  by  a  combination  of  two 
programs  written  in  C,  which  require  minimal  user  interaction.  Also,  two  “.com”  files 
written  in  Digital  Command  Language  (DCL)  are  used  for  file  searching  operations  and 
proper  execution  sequencing  of  the  two  C  programs.  The  results  produced  by  the  analysis 
are  stored  in  two  machine-readable  files;  one  contains  the  numerical  results  and  the  other 
serves  as  an  error  log. 
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Chapter  2 
Background 

2.1  Fundamentals  of  Fault  Tolerance 

A  computing  system  designated  to  perform  mission-critical  and  flight-critical 
tasks  must  maintain  a  high  level  of  reliability  since  faulty  operation  could  cause  loss  of 
aircraft  control  or  at  least  compromise  mission  effectiveness.  The  total  reliability  of  a 
system  is  a  function  of  the  individual  reliabilities  of  its  components  and  their  working 
relationships  with  one  another.  The  reliability  of  individual  components  is  always 
bounded  and  can  usually  be  determined  through  experimentation;  the  goal  of  fault 
tolerance  is  to  use  strategic  component  redundancy  to  achieve  a  system  reliability  which 
is  greater  than  that  of  the  individual  components.  By  definition,  a  fault-tolerant  system 
must  be  able  to  survive  erroneous  operation  by  some  subset  of  its  components  and  still 
properly  perform  all  assigned  tasks  [HAR91]. 

A  typical  reliability  goal  for  a  flight-critical  computer  system  is  1  failure  in  1 09 
hours,  while  the  components  of  that  system  may  exhibit  failure  rates  on  the  order  of  1  in 
104  hours  [HAR91].  Some  sort  of  redundancy  scheme  must  be  utilized  to  build  a  system 
that  is  103  times  more  reliable  than  its  individual  components.  One  approach  is  to  first 
examine  all  possible  failure  modes,  the  extent  of  their  effects,  and  their  associated 
probabilities  of  occurrence.  Then  the  system  is  designed  to  protect  against  all  potentially 
fatal  failure  modes  which  are  judged  to  have  a  significant  probability  of  occurring,  and 
the  design  must  address  a  sufficient  number  of  probable  failure  modes  such  that  the 
system  reliability  goal  is  achieved.  This  method  is  not  only  cumbersome  and  inexact,  but 
it  is  also  difficult,  if  not  impossible,  to  validate  the  reliability  of  the  design.  A 
mathematical  validation  of  the  design’s  reliability  requires  that  for  every  error  which 
occurs,  the  probability  that  the  design  does  not  adequately  protect  against  that  error  must 
be  less  than  10‘5  [HAR91].  It  is  certainly  conceivable  that  system  designers  could 
overlook  significant  types  of  erroneous  behavior  that  would  eventually  surface  in  field 
operation  at  the  expense  of  system  reliability.  It  is  therefore  preferable  to  employ  a 
design  methodology  that  addresses  only  the  number  of  potentially  fatal  component 
failures  and  ignores  the  exact  behavior  of  faulty  components;  this  is  the  objective  of  the 
Byzantine  resilience  approach  to  fault  tolerance. 

2.2  Fundamentals  of  Byzantine  Resilience 

Byzantine  resilience  guarantees  proper  operation  of  a  system  for  a  predefined 
number  of  component  failures,  regardless  of  the  specific  nature  of  the  individual  failures. 

13 


if 


ft 


j 


ft 


ft 


ft 


ft 


ft 


ft 


ft 


ft 


ft 


ft 


The  concept  of  Byzantine  resilience  is  derived  from  the  solution  to  the  Byzantine 
Generals  Problem;  it  is  stated  as  follows: 

1.  Imagine  several  divisions  of  the  Byzantine  army  camped  around  an  enemy 
stronghold;  each  division  has  its  own  commanding  general. 

2.  Upon  observation  of  the  enemy,  the  generals  must  decide  whether  to  attack  or 
retreat.  They  communicate  with  one  another  only  by  messenger. 

3.  Some  generals  may  be  traitors  and  thus  try  to  prevent  the  loyal  generals  from 
reaching  an  agreement.  All  messengers  are  considered  loyal;  traitorous 
activity  by  a  messenger  is  treated  as  traitorous  activity  by  the  general  sending 
the  message. 

4.  The  objective  is  to  develop  an  algorithm  to  guarantee  that  all  loyal  generals 
follow  the  same  plan  of  action,  and  no  small  number  of  traitors  can  cause  the 
loyal  generals  to  adopt  a  bad  plan  [LAM82]. 

This  problem  is  analogous  to  that  of  designing  reliable  computer  systems.  The 
commanding  generals  represent  processors  in  a  redundant  configuration,  the  traitors 
represent  faulty  processors,  and  the  messengers  correspond  to  the  interprocessor 
communication  links  [HAR91].  Using  this  analogy,  the  problem  may  be  restated  as 
follows: 

1.  A  redundant  computer  system  consists  of  multiple  processors. 

2.  The  processors  utilize  identical  inputs  to  produce  required  results.  They 
communicate  with  each  other  over  data  links. 

3.  Some  processors  may  be  faulty  and  may  demonstrate  malicious  and  even 
intelligent  behavior.  Faulty  communication  links  can  be  analytically  treated  as 
faulty  processors. 

4.  The  objective  is  to  force  the  system  outputs  to  reflect  an  agreement  among  the 
set  of  non-faulty  processors  and  to  effectively  mask  the  behavior  of  faulty 
processors. 

The  solution  to  this  problem  is  best  understood  after  explaining  some 
terminology.  The  physical  components  of  a  Byzantine  resilient  computer  system  are 
typically  organized  into  a  number  of  subsystems  referred  to  as  Fault  Containment 
Regions  (FCRs).  Each  FCR  has  a  certain  level  of  processing  power  and  maintains 
communication  links  with  other  FCRs  in  the  system.  By  definition,  any  fault  which 
occurs  within  an  FCR  should  not  be  propagated  outside  that  subsystem  to  other  FCRs.  A 
system  is  said  to  be  f-Byzantine  resilient  if  it  can  withstand  a  number  of  failures  that  is 
less  than  or  equal  to  f.  One  should  note  from  the  statement  of  the  problem  that  an  FCR 
failure  can  denote  any  type  of  malicious  or  even  intelligent  behavior,  and  this  ensures 
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proper  coverage  of  all  possible  failure  modes  as  long  as  the  number  of  failures  is  less  than 
or  equal  to  f.  The  solution  to  the  Byzantine  Generals  Problem  can  be  transformed  into  a  » 

set  of  implementation  requirements  for  an  f-Byzantine  resilient  system;  these  are 
summarized  as  follows: 

1.  There  must  be  at  least  3f+l  FCRs  [LAM82]. 

2.  Each  FCR  must  be  connected  to  at  least  2f+l  other  FCRs  through  disjoint  I 

communication  links  [DOL82]. 

3.  For  information  emanating  from  a  single  source,  there  must  be  at  least  f+1 
rounds  of  communication  among  FCRs  [FIS82] 

4.  The  activity  of  the  FCRs  must  be  synchronized  to  within  a  known  and  I 

bounded  skew  [DOL84]. 

For  a  1 -Byzantine  resilient  system,  there  must  be  four  FCRs  with  each  one 
uniquely  connected  to  the  other  three;  and  for  single  sourcing  of  information,  two  rounds 
of  communication  are  required.  A  minimal  1 -Byzantine  Resilient  System  is  shown  in  I 

Figure  2-1. 


Figure  2-1,  Minimal  1 -Byzantine  Resilient  System 


2.3  Illustrations  of  Byzantine  Resilience 

The  following  two  examples  illustrate  the  Byzantine  resilience  approach  to  fault- 
tolerant  computing. 

The  first  example  shows  how  communication  among  four  FCRs  in  a  1 -Byzantine 
resilient  configuration  can  overcome  faulty  operation  by  a  single  FCR.  Suppose  each 
FCR  contains  a  single  processor  and  all  four  processors  perform  the  same  operation. 
Also  assume  that  FCR  A  is  responsible  for  conveying  the  system  outputs  to  an  external 


15 


> 


actuator.  Simultaneously  all  four  processors  produce  results  for  some  required 
computation,  and  the  system  must  send  these  results  to  the  actuator. 

Figure  2-2  shows  that  the  processors  in  FCRs  B,  C,  and  D  all  reach  a  result  of  ‘  1  ’ 
while  the  processor  in  FCR  A  makes  an  error  and  submits  a  ‘O’  as  its  result.  In  order  to 
determine  the  output  for  the  system,  the  FCRs  perform  a  single  round  of  communication 
as  indicated  by  the  arrows,  and  each  FCR  then  knows  what  results  were  reached  by  all  the 
other  FCRs.  A  majority  vote  of  the  four  sets  of  data  is  performed  by  each  FCR,  and  since 
every  subsystem  works  with  the  same  set  of  four  data  values,  the  FCRs  necessarily  agree 
upon  the  proper  output  for  the  system.  Figure  2-2  shows  that  each  FCR  has  a  set  of  three 
‘l’s  and  one  ‘O’  upon  which  to  vote;  thus  they  must  reach  the  same  conclusion. 


Figure  2-2,  1 -Round  Data  Exchange 

The  result  of  the  inter-FCR  communication  and  voting  is  that  the  processor  in 
FCR  A  is  outvoted  and  the  system  result  is  given  as  a  ‘1.’  This  example  assumes  mat 
FCR  A  itself  is  not  faulty;  rather,  the  processor  in  FCR  A  experiences  a  temporary 
malfunction.  Despite  this  malfunction,  the  actuator  associated  with  FCR  A  still  receives 
the  correct  system  output,  and  this  is  shown  in  Figure  2-3.  Thus,  the  temporarily  faulty 
operation  of  a  single  processor  is  masked  in  the  system  output  of  this  1 -Byzantine 
resilient  configuration. 


I 


16 


Figure  2-3,  All  FCRs  Agree 


The  example  above  illustrated  the  use  of  the  “1 -round”  data  exchange.  This  type 
of  communication  is  known  as  a  voted  message,  and  it  is  used  when  an  exact  consensus  is 
expected  among  redundant  processors  performing  the  same  function.  Another  necessary 
form  of  communication  requires  two  rounds  of  data  exchange,  and  this  is  known  as 
passing  a  source  congruency  message.  A  “2-round”  exchange  is  required  when  a  single 
data  source  sends  information  to  a  specific  processor  or  a  group  of  processors  [AFTA91  ]. 
The  next  example  illustrates  this  type  of  communication  for  a  1 -Byzantine  resilient 
system. 

Suppose  there  is  a  sensor  associated  with  FCR  A,  and  it  wishes  to  send  data  to 
processors  in  each  of  the  four  FCRs.  Let  this  data  be  represented  by  a  binary  value  of  ‘  1 .’ 
Figure  2-4  shows  the  sensor  sending  its  data  to  FCR  A;  FCR  A  then  transmits  this 
information  to  all  the  other  FCRs.  This  is  the  first  round  of  data  exchange.  Note  that  the 
data  properly  reaches  FCRs  C  and  D,  but  an  error  between  FCRs  A  and  B  causes  B  to 
read  a  value  of  ‘0.’  This  type  of  fault  is  equivalent  to  traitorous  activity  by  FCR  B  or 
FCR  A;  without  loss  of  generality,  it  is  assumed  that  FCR  B  is  faulty. 

The  first  round  of  communication  is  followed  by  a  second  round  in  which  the 
FCRs  exchange  the  values  they  received  in  the  first  round.  Thus  FCRs  A,  C,  and  D  send 
out  Ts  to  all  their  neighbors,  and  the  traitor,  FCR  B,  sends  out  ‘0’s  to  all  of  its 
neighbors.  Assume  for  now  that  the  failure  of  FCR  B  to  properly  read  A’s  first  message 
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Figure  2-6  shows  that  all  four  FCRs  reach  a  consensus  value  of  ‘  1’  and  pass  this 
value  on  to  the  processors  associated  with  each  FCR.  Thus  the  second  round  of 
exchanges  allows  the  transient  fault  on  FCR  B  to  be  overcome  so  that  the  processor 
associated  with  FCR  B  could  receive  the  proper  value  from  the  sensor  attached  to  FCR  A. 


Figure  2-6,  Results  from  Example  #2 


Now  consider  the  case  where  FCR  B  exhibits  permanent  faulty  behavior  rather 
than  the  transient  fault  described  previously.  In  this  case,  B  could  send  out  any  random 
value  to  its  neighbors  and  also  read  back  random  values  for  the  messages  received  from 
its  neighbors.  This  means  it  would  be  improper  to  assume  that  FCR  B  votes  upon  the 
same  set  of  data  as  the  other  FCRs;  it  must  be  assumed  that  FCR  B  reaches  the  wrong 
value  and  its  processor  therefore  receives  faulty  data  from  the  sensor  attached  to  A.  This 
scenario  still  does  not  compromise  the  effectiveness  of  the  system  as  a  whole,  for  the 
perceived  faulty  operation  of  FCR  B  and  its  processors  is  masked  by  the  proper  operation 
of  the  remaining  FCRs.  This  property  is  demonstrated  in  the  first  example,  where  faulty 
operation  in  A  is  masked  by  correct  operation  of  FCRs  B,  C,  and  D. 

2.4  AFTA  Hardware  Architecture 

The  Army  Fault  Tolerant  Architecture  is  designed  as  a  1 -Byzantine  resilient 
system  organized  as  a  cluster  of  either  four  or  five  fault  containment  regions.  Each  FCR 
consists  of  a  network  element  (NE),  0  to  8  processing  elements  (PEs),  and  0  or  more 
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input/output  controllers  (IOCs)  for  interfacing  with  external  devices.  Figure  2-7 
illustrates  the  hardware  configuration  of  AFTA. 
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Figure  2-7,  AFTA  Hardware  Configuration  [AFTA91 ) 

Byzantine  resilience  requires  that  faults  within  one  FCR  do  not  alter  the  operation 
of  another  FCR;  thus  the  AFTA  design  allows  for  both  physical  and  dielectric  isolation  of 
FCRs.  Every  FCR  maintains  independent  clocking  and  has  its  own  power  source, 
backplane,  and  chassis.  The  only  physical  connection  between  FCRs  is  a  fully  connected 
high  speed  fiber  optic  network  which  provides  reliable  communication  without 
compromising  the  dielectric  isolation  [AFTA91 J. 


The  processing  elements  are  standard  processor  boards  with  local  memory  and 
miscellaneous  support  devices;  laboratory  prototype  tests  use  Motorola  68030  VME 
processor  boards.  The  PEs  are  organized  into  virtual  groups  (VGs)  with  one,  three,  or 
four  processors  per  group,  and  these  groups  are  referred  to  as  simplex,  triplex,  and 
quadruplex,  respectively.  VGs  with  multiple  processors  execute  an  identical  suite  of 
tasks  on  each  PE  to  provide  the  redundancy  needed  for  fault  tolerance,  and  Byzantine 
resilience  requires  that  every  member  of  a  triplex  or  quadruplex  VG  resides  in  a  different 
FCR.  Each  VG  operates  independendy  of  the  others,  and  the  combined  processing  power 
of  multiple  VGs  functioning  in  parallel  is  what  allows  the  AFTA  to  satisfy  its  high 
throughput  requirement.  A  minimal  AFTA  configuration  consists  of  four  FCRs  hosting  a 
single  virtual  group  of  three  PEs.  A  maximal  configuration  supports  forty  PEs  divided 
evenly  among  five  FCRs  [CLAS92],  The  virtual  group  configuration  in  this  case  can 
range  from  forty  simplexes  to  ten  quadruplexes.  Note  that  the  specific  virtual  group 
configuration  for  a  given  system  setup  depends  upon  performance,  reliability,  and 
availability  constraints,  and  can  include  mixed  redundancy  virtual  groups.  Figure  2-7 
illustrates  the  organization  of  forty  PEs  into  their  respective  VGs  as  well  as  the  physical 
separation  of  the  individual  members  of  redundant  VGs. 

The  core  of  each  FCR  is  the  network  element.  The  NE  maintains  the  fiber  optic- 
links  between  the  FCRs  and  also  keeps  the  FCRs  properly  synchronized.  The  network 
element  is  designed  to  implement  all  message  passing  and  data  voting  protocols  required 
by  Byzantine  resilience,  and  it  is  the  NE  that  actually  carries  out  the  communication 
between  the  PEs  within  a  VG  and  between  the  VGs  themselves.  The  PEs  communicate 
with  the  network  element  over  a  standard  bus  such  as  the  VME  bus  and  the  NEs  talk  to 
one  another  via  the  fiber  optic  network.  The  network  element  is  responsible  for  receiving 
messages  from  the  PEs  in  a  64-byte  packet  format,  transmitting  message  packets  over  the 
fiber  optic  network,  storing  message  packets  destined  for  PEs  within  its  FCR,  and 
notifying  its  PEs  of  message  packet  arrivals.  The  AFTA  operating  system  works  closely 
with  the  NE  hardware  to  ensure  that  the  necessary  communication  protocols  are 
implemented  smoothly,  and  the  result  is  that  the  entire  AFTA  communication  network 
can  be  viewed  as  a  virtual  bus  topology  with  all  processors  and  virtual  groups  tied  to  the 
bus  [AFTA91],  This  simplified  view  of  the  AFTA  is  shown  in  Figure  2-8.  Message 
passing  between  virtual  groups  occurs  asynchronously  over  this  virtual  bus,  and  the 
hardware  is  designed  to  guarantee  that  message  packets  are  delivered  correctly  and  in 
order. 
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Figure  2-8,  AFTA’s  Virtual  Bus  Topology  [AFTA91] 

The  AFTA  provides  a  unique  combination  of  parallel  processing  and  fault 
tolerance  capabilities,  and  the  inherent  complexity  of  these  combined  disciplines  could 
cause  unnecessary  difficulty  for  software  developers.  Fortunately,  the  custom  design  of 
the  network  element  and  the  AFTA  operating  system  make  the  system’s  hardware 
configuration  relatively  transparent  to  application  task  programmers  [HAR91].  The 
programmer  does  not  need  to  understand  the  requirements  of  Byzantine  resilience  or  the 
subtleties  of  parallel  processing.  The  operating  system  provides  a  set  of  message  passing 
services  that  allow  an  applications  developer  to  perform  intertask  communication  via 
simple  function  calls.  Thus  the  programmer  must  know  only  the  global  communication 
identification  for  the  tasks  with  which  he  communicates;  he  may  ignore  the  actual  virtual 
group  configuration  and  physical  system  setup.  This  thesis  primarily  views  the  AFTA  at 
this  level  of  abstraction. 

2.5  Rate  Group  Scheduling  Overview 

The  AFTA  is  designed  specifically  to  support  hard-real-time  application  tasks, 
and  a  rate  group  scheduling  paradigm  is  utilized  to  achieve  hard-real-time  response  for 
both  periodic  and  aperiodic  tasks  [CLAS92].  A  hard-real-time  task  is  a  process  that  is 
executed  in  an  iterative  manner  such  that  every  execution  cycle  is  completed  prior  to  a 
predefined  deadline.  Typically  a  task  is  allotted  a  certain  time  frame  in  which  to  execute, 
and  if  execution  is  incomplete  at  the  time  of  the  deadline,  a  frame  overrun  condition  is  in 
effect.  A  frame  overrun  denotes  a  failure  on  the  part  of  system  task  scheduling,  and  it 
could  lead  to  catastrophic  results  if  the  outputs  of  a  task  are  critical  to  a  function  such  as 
flight  control. 

The  AFTA’s  processing  resour:  <*n  n,'  software  task  assignments  are  logically 
divided  among  the  system’s  virtual  groups.  Each  virtual  group  is  responsible  for 
scheduling  the  execution  of  its  own  set  of  tasks,  and  it  utilizes  a  combination  of  two 
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scheduling  algorithms.  The  first  is  rate  group  scheduling;  it  is  useful  for  tasks  with  well- 
defined  iteration  rates  and  guaranteed  maximum  execution  times  (i.e.  flight  control 
functions).  The  second  method  is  aperiodic  non-real-time  scheduling,  and  this  is  used  for 
non-real-time  tasks  whose  iteration  rate  is  unknown  or  undefined  (i.e.  mission  planning). 
Note  that  the  task  scheduling  algorithms  do  not  allow  non  rate  group  tasks  to  disturb  the 
critical  timing  behavior  of  rate  group  tasks  [CLAS92]. 

In  the  rate  group  scheduling  paradigm,  the  real-time  tasks  on  a  single  VG  are 
categorized  according  to  their  required  iteration  rates.  Presently  the  AFTA  supports  four 
rate  group  designations;  the  names,  frequencies,  and  frame  allocations  of  these  groups  are 
summarized  in  Table  2-1  [AFTA91]. 


Table  2-1,  Rate  Group  Designations 


Iteration  Rate 

Iteration  Frame 

RG4 

100Hz 

10ms 

RG3 

50Hz 

20ms 

RG2 

25Hz 

40ms 

RG1 

12.5Hz 

80ms 

At  any  given  instant  of  time,  all  four  rate  group  frames  are  simultaneously  active, 
although  the  processing  power  of  the  virtual  group  is  dedicated  to  only  one  task  within 
one  rate  group.  Rate  group  preemption  is  allowed  such  that  tasks  within  a  faster  rate 
group  are  always  able  to  interrupt  tasks  within  a  slower  rate  group  and  thus  divert 
processing  power  to  ensure  that  higher  frequency  tasks  complete  execution  before  their 
next  deadline.  For  example,  if  an  RG3  task  is  executing  when  a  new  RG4  frame  begins, 
the  RG3  task  is  suspended  in  favor  of  RG4  tasks.  All  RG4  tasks  execute  to  completion, 
and  then  execution  of  the  suspended  RG3  task  is  resumed. 


minor  frame  index: 


Figure  2-9,  Rate  Group  Frame  Organization 
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Figure  2-9  serves  as  a  pictorial  explanation  of  the  organization  of  rate  group  frames 
relative  to  one  another  for  a  single  virtual  group.  Notice  that  for  an  80ms  slice  of  time 
(one  RG1  frame),  RG4  tasks  are  executed  8  times,  RG3  tasks  are  executed  4  times,  RG2 
tasks  are  executed  twice,  and  RG1  tasks  are  executed  once. 

For  a  given  rate  group  frame,  the  VG  schedules  tasks  on  a  static,  non  preemptive 
basis  [CLAS92].  In  other  words,  tasks  within  the  same  rate  group  cannot  interrupt  one 
another  even  though  higher  frequency  tasks  are  allowed  to  interrupt,  and  the  ordering  of 
tasks  within  the  rate  group  frame  depends  upon  a  task  priority  assignment  made  during 
system  initialization.  Despite  the  preemptive  activity  between  tasks  of  different  rate 
groups,  each  task  on  a  VG  should  eventually  execute  until  it  reaches  a  state  of  self¬ 
suspension.  For  each  rate  group  frame,  every  task  in  that  rate  group  must  enter  self¬ 
suspension  before  the  frame  boundary;  failure  to  do  so  constitutes  a  frame  overrun. 
When  a  task  suspends  its  own  execution,  it  has  effectively  completed  its  execution  cycle 
and  the  VG’s  processing  power  is  passed  on  to  another  task.  At  the  beginning  of  a  new 
rate  group  frame,  every  task  in  the  rate  group  is  once  again  scheduled  for  execution  and 
resumes  execution  at  the  point  where  it  last  suspended  itself.  Figure  2-10  shows  how 
tasks  are  scheduled  within  an  arbitrary  rate  group  frame.  Notice  that  incoming  messages 
are  delivered  to  the  rate  group  tasks  at  the  beginning  of  the  frame  and  outgoing  messages 
are  queued  during  the  frame  and  then  transmitted  at  the  end  of  the  frame. 


Beginning  of 
Rate  Group 
Frame 


R4:  10  ms 
-R3:  20  ms- 
R2: 40  ms 
Rl:  80  ms 


Tasks  within  Rate  Group 


End  of  Rate 
Group  Frame 


T1 

T2 

T3 

T4 

T5 

:  ;4ill 

Inputs  and  Messages 
Delivered  to  Rate 
Group  Tasks 


Outputs  and  Messages 
Delivered  to  Rate 
Group  Tasks 


Figure  2-10,  Scheduling  for  a  Single  Rate  Group  Frame 
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The  actual  task  scheduling  for  a  virtual  group  is  performed  by  an  RG4  task  known 
as  the  rate  group  dispatcher.  It  executes  at  the  beginning  of  every  minor  frame  (RG4 
frame)  and  schedules  execution  of  all  tasks  belonging  to  rate  groups  whose  frame 
boundaries  coincide  with  the  beginning  of  the  current  RG4  frame.  Refer  to  Figure  2-9  for 
a  good  illustration  of  the  frame  boundary  synchronization. 

The  rate  group  dispatcher  also  performs  several  bookkeeping  functions  for  the 
operating  system,  and  it  triggers  transmission  of  the  messages  that  were  queued  during 
the  rate  group  frames  that  were  just  terminated.  Any  task  overruns  from  the  previous 
frames  are  detected  by  the  RG  dispatcher,  and  the  error  handling  system  is  notified.  In 
the  case  of  an  overrun,  the  RG  dispatcher  detects  which  tasks  were  unable  to  complete 
execution  and  enter  self-suspension  [CLAS92],  It  is  possible  that  a  task  which  causes  an 
overrun  actually  completes  its  execution  and  effectively  forces  lower  priority  and  lower 
frequency  tasks  to  remain  incomplete.  Thus,  the  source  of  this  type  of  overrun  error  is 
very  difficult  to  trace,  and  it  is  intended  that  the  type  of  a  priori  configuration  timing 
analysis  proposed  by  this  thesis  will  prevent  the  occurrence  of  such  errors. 
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Chapter  3 

Preliminary  Processing 

3.1  Requirements 

The  AFTA  timing  analysis  is  divided  into  three  distinct  stages  -  preliminary 
processing,  software  modeling,  and  hardware  modeling.  Each  stage  builds  upon  the 
results  of  the  previous  stage(s)  and  contributes  to  the  formulation  of  final  results.  The 
analysis  begins  with  the  preliminary  processing  stage,  and  its  primary  function  is  to 
provide  the  other  stages  with  an  accurate  and  concise  picture  of  the  system  configuration. 
One  of  the  goals  of  the  timing  analysis  is  to  minimize  user  interaction  so  that  the 
computer  bears  the  brunt  of  the  analysis  workload,  and  the  preliminary  processing  phase 
is  designed  to  gather  its  information  in  an  automated  fashion  from  existing  software  files 
and  avoid  querying  the  user  about  the  system  setup.  The  user  is  only  required  to  provide 
the  name  of  the  current  task  specification  file;  the  analysis  software  does  the  rest. 

Both  the  hardware  and  software  analysis  stages  depend  upon  the  configuration 
information  provided  by  the  preliminary  processing  stage;  however,  these  two  types  of 
analysis  view  the  system  from  different  perspectives.  The  software  analysis  develops 
models  of  the  application  task  source  code,  and  it  sees  the  system  as  a  collection  of  task 
instantiations.  The  hardware  analysis  performs  calculations  relevant  to  the  rate  group 
timing  deadlines,  and  it  sees  the  system  as  a  collection  of  virtual  groups.  The  goal  of  the 
preliminary  processing  is  to  find  the  information  required  by  both  the  software  and 
hardware  analyses  and  to  provide  it  in  a  format  that  is  useful  to  both. 

The  gathering  of  system  configuration  data  focuses  upon  the  individual 
application  tasks,  and  the  preliminary  processing  stage  seeks  answers  to  the  following 
questions: 

1.  What  are  the  names  of  all  application  tasks  in  the  suite? 

2.  On  which  virtual  group(s)  does  each  task  reside? 

3.  To  which  rate  group  does  each  task  belong? 

4.  What  are  the  message  passing  limitations  for  each  task? 

5.  Which  file  contains  the  source  code  for  each  task? 

With  regard  to  formatting  this  information,  notice  that  the  setup  data  is  easily  organized 
according  to  tasks.  This  is  a  convenient  format  for  the  software  analysis,  but  it  is  also 
easily  transformed  it  into  a  virtual  group  format  for  the  convenience  of  the  hardware 
analysis.  This  transformation  is  explained  in  Chapter  8. 
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3.2  Inputs 

Ada  software  development  and  maintenance  for  the  AFTA  currently  takes  place 
on  a  VAX  minicomputer.  During  AFTA  testing,  application  task  code  is  transferred  from 
the  VAX  file  server  to  the  AFTA’s  processing  elements,  and  in  the  process,  the  operating 
system  is  provided  with  a  task  specification  file,  which  essentially  explains  the  software 
setup  to  the  operating  system.  The  preliminary  processing  phase  utilizes  this  file  to 
gather  most  of  its  configuration  information.  The  file  is  organized  as  a  series  of  records 
with  each  record  containing  information  about  a  single  task  instantiation.  A  sample  entry 
is  shown  below  in  Figure  3-1. 


Figure  3-1,  Sample  Task  Specification  File  Entry 


Since  the  format  here  is  somewhat  cryptic,  it  requires  some  explanation.  Figure  3-1 
shows  the  first  task  entry  in  the  file,  as  denoted  by  the  “1  =>.”  The  gc  i  d  and  gt  i  d  lines 
refer  to  the  task’s  global  communication  identification  and  global  task  identification, 
respectively,  and  these  are  necessary  for  message  passing  purposes.  The  name  of  the  task 
is  f  d  i ,  and  it  is  extracted  from  the  line  “gt  i  d=  >gt  i  ds  .  f  d  i .”  f  d  i  is  a  software 
service  that  performs  fault  detection  and  isolation;  by  convention,  a  “_t”  is  appended  to 
the  task  name,  and  the  source  code  for  f  d  i  is  found  in  a  task  body  named  f  d  i  _t .  Note 
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that  there  is  not  necessarily  any  correlation  between  the  name  of  the  task  and  the  name  of 
the  package  or  file  where  it  is  held.  The  I  ocat  i  on  line  shows  that  f  d  i  is  configured  to 
execute  on  all  virtual  groups  in  the  system;  a  task  can  be  configured  to  run  on  all  VGs 
simultaneously  or  only  on  one  VG.  The  “yg  =  >0”  line  shows  which  VG  hosts  the  task;  in 
this  case,  “0”  is  used  because  the  task  is  mapped  to  all  operational  VGs.  The  rg  line 
indicates  that  f  d  i  is  an  RG4  task,  and  its  precedence  value  determines  how  it  is 
mapped  statically  within  an  RG4  execution  frame.  The  next  group  of  four  lines  refers  to 
the  message  buffering  requirements  of  the  task.  max_xmit_3ize  and 
max_rcue_3  i  ze  indicate  the  maximum  size,  in  bytes,  of  messages  that  the  task  is 
allowed  to  transmit  and  receive.  Likewise,  Riax_xm  i  t_num  and  max_rcue_num 
determine  the  maximum  number  of  messages  a  task  can  send  and  receive  during  a  single 
execution  cycle.  The  final  portion  of  the  record  concerns  I/O  requests,  and  this 
information  is  currently  irrelevant  to  the  timing  analysis. 

Similar  to  the  AFTA  application  software,  the  timing  analysis  program  is  resident 
on  the  VAX.  All  file  manipulations  in  the  course  of  the  analysis  take  place  on  the  VAX, 
completely  separate  from  the  actual  FTPP.  The  user  provides  the  analysis  program  with 
the  task  specification  filename,  and  the  preliminary  processing  begins  with  an 
examination  of  this  file. 

3.3  Tools 

The  preliminary  processing  stage  consists  of  one  C  program  named  START.C  and 
one  DCL  program  called  FIND.COM.  The  execution  of  the  C  program  is  explained  in 
this  section  and  the  following  section;  the  DCL  file  is  examined  in  Section  3.5.  Source 
code  listings  are  included  as  Appendices  B  and  C,  respectively. 

START.C  utilizes  some  simple  tools  to  examine  the  task  specification  file  and 
pass  on  the  information  it  finds  to  the  DCL  program  and  to  future  stages  of  the  timing 
analysis.  The  first  tool  is  a  procedure  called  r ead_ I i st .  Its  function  is  to  read  a  pre¬ 
defined  file  which  lists  a  series  of  key  words  that  are  needed  by  START.C  when 
examining  the  task  specification  list,  read- 1  i  st  opens  the  file,  grabs  each  key  word 
individually,  and  stores  it  in  a  structure  called  search-  list. 

The  next  procedure  is  get  - 1  i  ne;  its  function  is  to  pull  characters  from  the  task 
specification  file  and  assemble  them  into  words  and  assemble  the  words  into  individual 
lines.  In  this  case,  a  line  refers  to  the  string  of  characters  found  between  carriage  returns. 
Whenever  it  is  called,  get  - 1  i  ne  finds  and  returns  the  next  line  in  the  file.  The  line  is 
stored  as  a  collection  of  words  in  a  structure  called  t  h  i  s_  I  i  ne;  all  white  space  and 
comments  are  deleted  from  the  line. 
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The  procedure  called  search  is  the  workhorse  of  start .  c.  Its  job  is  to  search 
a  single  line  of  the  task  specification  file  looking  for  the  key  words  stored  in 
search- 1  ist.  When  a  key  word  is  found,  it  means  that  there  is  vital  information  in 
that  line,  and  a  specific  procedure  is  called  to  extract  that  information.  All  relevant  data 
found  in  the  file  is  stored  in  a  structure  called  task;  its  format  is  shown  in  the 
pseudocode  of  Figure  3-2: 


task  record 

(structure) 

name 

(string) 

virtual  group 

( integer) 

rate  group 

( integer) 

message  buffers 

(structure) 

max  transmit  size 

( integer) 

max  transmit  number 

( integer) 

max  receive  size 

( i nteger ) 

max  receive  number 

( integer) 

Figure  3-2,  Task  Information  Storage  Format 


The  last  major  procedure  is  uir  i  te_f  i  I  e,  and  its  function  is  to  use  the  task 
structure  to  generate  two  temporary  output  files  for  the  DCL  program  and  the  software 
modeling  stage.  The  first  file  is  “task_names.dat,”  and  it  contains  a  simple  listing  of  all 
the  task  names  in  the  suite.  The  second  file  is  “list_of_tasks.dat,”  and  it  is  a  listing  of  all 
the  information  contained  in  task,  with  one  line  devoted  to  each  task  instantiation  and 
its  associated  data. 

The  other  procedures  used  by  START.C  are  extract_name,  get_rg,  and 
strip.  These  are  minor  functions  needed  for  gathering  data  from  the  individual  lines  of 
the  task  specification  file. 

3.4  Flow  of  Execution 

START.C  is  a  simple  series  of  procedure  calls  to  extract  information  from  the  task 
specification  file,  organize  it,  and  pass  it  on  through  temporary  files.  It  begins  with  a  call 
to  read— I  i  st,  and  this  is  followed  by  a  filename  inquiry.  The  task  specification  file  is 
opened,  and  then  an  iterative  search  process  begins,  get- I  ine  is  used  to  grab 
successive  lines  from  the  file,  and  each  call  to  get- 1  ine  is  followed  by  a  call  to 
search.  Thus  the  file  is  examined  one  line  at  a  time  until  get_  I  i  ne  signals  that  the 
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end  of  the  file  has  been  reached.  All  information  gathered  is  placed  in  the  structure 
task,  and  »r  i  t e_f  i  I  e  is  invoked  to  produce  the  two  output  files  described  above. 
Figure  3-3  illustrates  the  flow  of  input  and  output  files  for  the  preliminary  processing 
stage. 

3.5  The  DCL  Program 

FIND.COM  is  an  elementary  file  search  program  written  in  Digital  Command 
Language  (DCL).  Its  purpose  is  to  find  the  files  which  contain  the  source  code  for  each 
application  task  in  the  task  suite.  There  is  no  convention  which  demands  that  the 
filename  in  any  way  relates  to  the  name  of  the  task;  also  multiple  tasks  could  be  found  in 
a  single  file.  Of  cot’ '  e,  it  1  assumed  that  the  user  already  knows  where  the  source  code 
can  be  found,  but  fa  ..rposes  of  automation,  FIND.COM  is  utilized  to  avoid  having  the 
user  enter  the  filenames  for  the  various  application  tasks. 


Figure  3-3,  Preliminary  Processing  File  Flow 

The  Digital  Command  Language  has  a  powerful  search  command  which  allows  a  I 

programmer  to  specify  a  word  or  group  of  words  and  then  search  all  files  in  any  number 
of  directories  to  find  occurrences  of  that  word  group.  FIND.COM  is  programmed  to 
search  a  specified  set  of  directories  where  source  code  should  be  located.  It  first  searches 
for  the  occurrence  of  the  phrase  “task  body  is;”  this  phrase  signifies  the  presence  of  task  » 

source  code.  All  filenames  containing  this  phrase  are  stored  in  a  file  called  “temp.dat.” 

This  is  followed  by  a  second  search  in  which  the  previously  identified  files  are  again 

searched  for  the  individual  task  names  listed  in  “task_names.dat.”  When  a  file  is  found  to 

hold  a  specified  task,  the  task  name  and  filename  are  recorded  together  in  an  output  file  I 

called  “filenames.dat.”  The  interaction  of  input  and  output  files  is  shown  in  Figure  3-3. 
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In  conclusion,  the  preliminary  processing  phase  is  relatively  simple,  but  it  really  is 
essential  to  the  analysis  because  the  hardware  and  software  modeling  depend  upon  the 
configuration  data.  The  details  of  pre-processing  are  not  critical  to  the  analysis;  what  is 
important  is  an  understanding  of  the  origin,  motivation  for,  and  contents  of  the  two  output 
files  --  “filenames.dat”  and  “iist_of_tasks.dat.” 


Chapter  4 
Software  Analysis 

4.1  Assumptions  and  Limitations 

The  software  analysis  is  the  second  stage  in  the  progression  of  the  AFTA  timing 
analysis;  its  function  is  to  examine  the  source  code  for  the  application  task  suite,  develop 
a  parameterized  model  for  each  task  individually,  and  pass  that  model  on  to  the  hardware 
analysis  stage  to  produce  the  desired  timing  results.  The  ultimate  goal  of  the  software 
analysis  is  to  define  a  worst  case  bound  on  execution  time  for  any  single  cycle  of  an 
application  task.  Recall  that  this  information  is  necessary  for  the  prevention  of  dynamic 
performance  failures  as  described  in  Chapters  1  and  2.  The  difficulty  of  predicting 
software  execution  delay  grows  as  the  complexity  of  the  code  increases.  High  level 
languages  such  as  Ada  give  the  programmer  a  great  deal  of  latitude  in  formulating  a 
task’s  structure  and  flow  of  execution,  and  the  problem  of  predicting  execution  time 
through  a  static  analysis  of  source  code  is  almost  unmanageable.  For  this  reason,  some 
simplifying  assumptions  must  be  made,  and  the  goals  of  the  software  analysis  must  be 
further  defined. 

The  fundamental  assumption  for  the  software  analysis  is  that  task  execution  time 
can  be  accurately  modeled  according  to  a  limited  set  of  known  functions,  which  are  called 
in  the  course  of  code  execution.  At  this  point  in  the  AFTA’s  development,  the  set  of 
known  functions  primarily  consists  of  benchmarked  operating  system  calls  [CLAS92], 
but  in  the  future,  any  commonly  used  function  can  be  benchmarked  and  added  to  the 
model.  The  source  code  analysis  seeks  to  parameterize  a  task  by  determining  how  many 
times  each  of  the  known  functions  is  called  during  a  single  execution  cycle  under  worst 
case  conditions.  Since  the  delay  for  each  function  can  be  carefully  designed  and 
benchmarked  to  be  a  deterministic  quantity,  some  simple  algebraic  manipulation  is  used 
to  arrive  at  an  estimated  lower  bound  on  worst  case  task  execution  time. 

Notice  that  the  timing  analysis  produces  a  lower  bound  on  worst  case  delay,  not 
an  upper  bound  as  one  might  expect.  This  is  due  to  the  fact  that  the  task  source  code  is 
modeled  as  an  accumulation  of  function  calls,  where  each  call  adds  a  known  delay  to  the 
,  total  worst  case  execution  time.  The  set  of  functions  included  in  the  code  model  does  not 
account  for  all  of  the  processing  performed  by  a  task;  this  is  clarified  in  the  explanation  of 
the  code  model  found  in  Chapter  5.  It  is  probable  that  a  substantial  amount  of  processing 
activity  within  the  task  could  be  overlooked  by  the  model  if  such  activity  does  not  qualify 
as  a  known  deterministic  quantity.  This  is  why  the  timing  analysis  can  only  produce  a 
lower  bound  on  worst  case  execution  time;  an  upper  bound  would  have  to  account  for  all 
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processing  activity,  and  that  is  not  possible  for  the  code  model  developed  in  this  thesis. 
The  objective  here  is  to  construct  a  flexible  model  for  source  code  that  will  produce 
increasingly  accurate  results  as  the  model  develops  and  becomes  more  sophisticated. 
Though  it  is  not  known  exactly  how  a  single  task’s  execution  times  may  be  distributed, 
Figure  4-1  shows  an  exponential  distribution  as  a  reasonable  possibility.  Given  this 
assumption,  it  is  the  goal  of  the  software  analysis  to  produce  a  worst  case  estimate  that 
falls  on  the  far  right  side  of  the  curve.  Since  this  analysis  provides  only  a  lower  bound  on 
worst  case  delay,  the  estimate  will  never  be  on  the  extreme  right,  but  as  the  AFTA 
benchmarking  efforts  proceed  and  the  code  model  grows  and  improves,  the  delay 
estimate  should  shift  significantly  toward  the  tail  of  the  curve. 

Worst  Case  Estimate 


Figure  4-1,  Possible  Distribution  of  Execution  Times 

The  software  analysis  works  with  Ada  source  code,  and  it  is  assumed  that  the  code 
has  been  compiled  and  is  free  of  errors.  The  analysis  is  heavily  dependent  upon  Ada 
syntax  rules  in  extracting  correct  information  from  the  source  code,  and  in  fact, 
compliance  with  Ada  syntax  rules  is  the  only  guarantee  afforded  to  the  analysis  tool  when 
it  encounters  a  segment  of  code.  All  programmers  develop  their  own  style  and  use 
unique  text  formatting  and  code  structuring.  For  this  reason,  it  is  imperative  that  the 
software  analysis  is  able  to  understand  any  legal  code  construct,  rather  than  being  tuned 
to  accept  a  predefined  code  format.  This  allows  full  flexibility  to  the  application  task 
programmer,  and  at  the  same  time,  it  makes  the  software  analysis  quite  complex. 

The  element  of  style  flexibility  also  imposes  some  limitations  on  the  effectiveness 
of  a  static  code  analysis,  for  there  are  instances  where  it  is  useful  to  know  the  value  of  a 
variable,  but  because  of  the  variable’s  definition  and  the  flow  of  execution,  a  static 
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analysis  is  not  able  to  define  that  value.  In  such  cases,  the  analysis  relies  upon  extraneous 
information  from  the  programmer  in  the  form  of  comments,  and  if  these  comments  are 
not  included,  default  values  must  be  assumed.  The  individual  programmer  makes  the 
decision  whether  or  not  to  include  the  extra  information,  and  if  he  chooses  not  to  do  so, 
the  analysis  is  dependent  upon  default  values  which  could  be  highly  inaccurate. 

Another  limitation  of  the  software  analysis  arises  from  the  fact  that  there  is 
currently  a  lack  of  actual  application  task  code  available  for  the  AFTA.  Since  the  AFTA 
is  only  a  prototype  at  this  stage,  software  development  efforts  are  primarily  focused  on 
the  operating  system,  with  application  task  development  being  deferred.  This  serves  to 
limit  the  amount  of  operational  testing  that  can  be  done  with  timing  analysis.  Certainly, 
as  a  greater  quantity  and  variety  of  task  code  is  made  available  for  testing,  the  timing 
analysis  will  be  modified  and  improved.  The  fact  that  this  analysis  tool  must  be  able  to 
comprehend  code  that  is  not  yet  written  reinforces  the  concept  of  allowing  the 
applications  programmer  full  latitude  in  the  realm  of  style  and  assuming  nothing  about 
the  source  code  except  Ada  syntax  compliance.  To  date,  the  analysis  tool  has  only  been 
tested  on  the  fault  detection  and  isolation  software  written  for  the  AFTA. 

4.2  The  Ada  Software  Structure 

The  Ada  programming  language  is  designed  specifically  for  large,  real-time, 
embedded  computer  systems,  and  it  was  created  as  a  Department  of  Defense  standard  for 
software  engineering.  As  such,  Ada  was  chosen  to  be  the  language  for  software 
development  on  the  AFTA  [AFTA91].  An  intimate  knowledge  of  the  Ada  programming 
language  is  not  necessary  for  one  to  understand  the  AFTA  timing  analysis,  but  a 
simplified  understanding  of  the  code  framework  is  useful. 

4.2.1  Subprograms  and  Packages 

Ada  code  structures  can  be  divided  into  three  primary  types  of  program  units: 
subprograms,  packages,  and  tasks.  These  program  units  generally  have  a  two-part 
structure  consisting  of  a  specification  and  a  body.  The  specification  details  the  interface 
to  the  unit,  and  the  body  contains  the  unit  implementation  details  which  can  be  logically 
hidden  behind  the  interface  [B0087].  The  AFTA  software  analysis  is  interested  in  only 
the  program  body;  the  specification  is  generally  ignored. 

Ada  subprograms  are  the  basic  units  of  execution,  and  the  body  of  a  subprogram 
holds  the  sequence  of  statements  that  define  some  algorithm.  Subprograms  are  divided 
into  two  classes:  functions  and  procedures.  The  software  analysis  deals  primarily  with 
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procedures,  but  the  methods  presented  in  this  thesis  are  fully  applicable  to  functions  as 
well. 

An  Ada  package  is  a  unit  of  encapsulation  which  allows  the  programmer  to  group 
logically  related  entities  such  as  subprograms  and  tasks.  The  software  analysis  relies 
upon  examination  of  package  bodies  to  find  source  code  for  application  tasks  and  relevant 
procedures.  Note  that  task  source  code  is  always  enclosed  within  a  package. 

4.2.2  Tasks 

Ada’s  real-time  processing  capabilities  are  based  upon  the  use  of  program  units 
known  as  tasks.  A  task  is  defined  as  an  entity  that  can  operate  concurrently  with  other 
program  units  [B0087],  and  the  central  concern  of  the  software  analysis  is  the 
examination  of  application  task  source  code.  A  rate  group  task  must  have  a  well-defined 
cyclic  execution  behavior,  and  it  should  never  reach  a  point  of  termination  until  system 
shutdown.  These  characteristics  imply  an  infinite  loop  structure  for  a  task,  and  this  is 
shown  in  the  following  sample  code  fragment. 


with  scheduler; 

package  body  appl_test  is 
task  body  app I 1_t  i 3 

roy_cid  :  constant  commun i cat i on_i d_type  :=  app  I  1 ; 
num_deleted  :  natural  :=  0; 
f rame_ t i roe  :  time  : =  startup-time; 
beg  i  n 
I  oop 

scheduler.  u»ait_  f  or_ schedu  I  e ; 
end  loop; 

end  app 1 1 _ t ; 

end  app l_t est ; 


Figure  4-2,  Sample  Rate  Group  Task 


Figure  4-2  illustrates  the  general  code  framework  an  application  task.  The 
statement  with  schedu  I  er  signals  the  inclusion  of  all  subprograms  in  an  external 
package  called  schedu  I  er.  This  is  followed  by  the  definition  of  the  package  body  for 
app  I  _ t  est ,  which  includes  the  body  for  a  single  application  task  known  as  app  I  1  _t 
The  definition  of  my_c  i  d  is  necessary  for  intertask  communication,  and  num_de  I  et  ed 
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refers  to  the  number  of  messages  deleted  in  the  previous  frame  due  to  inadequate 
buffering.  The  variable  f rame_t  i  me  contains  the  value  of  the  time  when  the  current 
rate  group  frame  was  started.  These  variables  are  unimportant  to  the  software  analysis; 
what  is  critical  to  note  here  is  the  structure  of  task  app  1 1 .  Figure  4-2  shows  app  11  as  a 
minimal  rate  group  task  consisting  of  an  infinite  loop  surrounding  a  single  call  to  the 
via  i  t_fcr_schedu  I  e  procedure  that  is  defined  within  the  achedu  I  er  package.  The 
infinite  loop  ensures  that  app  I  1  executes  in  an  iterative  manner  for  an  -finite  length 
of  time,  and  the  call  to  uia  i  t_for_achedu  I  e  -illows  app  I  1  to  suspend  itself  after 
each  progression  through  the  loop.  The  task  is  revived  when  scheduled  by  the  rate  group 
dispatcher  during  its  next  rate  group  frame.  Thus,  the  uia  i  t_f  or_3chedu  I  e  call 
regulates  the  rate  group  behavior  of  a  task  in  the  following  manner: 

1.  A  task  begins  execution  when  scheduled  by  the  rate  group  dispatcher. 

2.  When  a  task  finishes  a  single  execution  cycle  (in  this  case,  one  progression 
through  the  infinite  loop),  it  calls  uia  i  t_f  or_schedu  I  e. 

3.  The  task  then  enters  a  state  of  self-suspension,  and  its  processing  resources  are 
freed  for  use  by  other  tasks. 

4.  When  the  next  rate  group  frame  begins,  the  rate  group  dispatcher  scnedules 
the  task  for  another  execution  cycle. 

5.  Once  scheduled,  the  task  begins  execution  with  the  code  immediately 
following  the  last  uia  i  t_f  or_schedu  I  e  call  and  proceeds  until  it 
encounters  another  uia  i  t_f  or_schedu  I  e  call. 

The  progression  of  events  described  above  is  the  basis  of  the  software  analysis. 

4.3  Requirements  of  the  Programmer 

One  of  the  goals  of  the  software  analysis  is  to  be  able  to  accept  and  comprehend 
source  code  written  in  almost  any  programming  style,  provided  that  the  code  complies 
with  Ada  syntax  rules.  In  general,  the  programmer  is  not  restricted  to  following  any  pre¬ 
defined  format  for  the  benefit  of  the  timing  analysis;  however,  there  are  a  limited  number 
of  simple  directives  that,  if  followed,  make  the  anal,  ..is  much  more  effective. 

4.3.1  Comment  Information 

When  one  performs  a  manual  static  analysis  of  source  code,  it  is  quite  easy  to  scan 
the  code  both  forwards  and  backwards  to  extract  the  information  needed  to  trace  the  flow 
of  a  program.  The  human  mind  is  capable  of  performing  complex  searches  for  variable 
value.-  through  many  levels  of  definition,  and  one  can  almost  mentally  simulate  source 
code  a;  he  reads  it.  Unfortunately,  such  a  manual  analysis  is  impractical  and  prone  to 
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errors  when  dealing  with  exceptionally  large  bodies  of  code;  thus,  in  the  interest  of  speed 

and  accuracy,  automated  analysis  replaces  manual  analysis.  The  problem  is  that  it  is  a 

difficult  task  to  train  a  computer  to  read  and  understand  source  code  the  same  way  that  a  I 

human  would,  and  in  order  to  simplify  this  task,  some  compromises  must  be  made. 

The  first  compromise  is  to  force  the  computer  to  read  code  in  only  the  forward 
direction.  Certainly  it  is  possible  to  have  the  computer  search  a  piece  of  code  in  both 
directions  to  find  information,  but  the  logic  to  control  such  a  search  involves  unjustifiable  I 

complexity.  Therefore  the  AFTA  software  analysis  reads  and  examines  source  code  one 
line  at  a  time  in  the  order  in  which  it  is  encountered.  Any  information  that  could  be 
useful  later  in  the  analysis  must  be  properly  extracted  and  stored  (or  remembered) 
because  there  is  no  way  to  refer  back  to  code  that  has  already  been  processed.  This  I 

approach  may  seem  to  be  too  limited,  but  the  implementation  of  some  simple  strategies 
make  it  sutprisingly  effective. 

One  limitation  of  single-line  processing  is  its  inability  to  fully  trace  variable 
values.  This  is  easily  demonstrated  with  the  following  example:  I 

task  body  examp I e_t  is 

counter  :  natural  :=  50; 
i  :  natura 1 ; 
beg  i  n 
I  oop 

for  i  in  1  .  .  counter  I oop 
end  loop; 

scheduler. uiai  t_f  or_schedu  1  e ; 
counter  :=  100; 
end  loop; 
end  example_t; 

Figure  4-3,  Variable  Tracing  Example  #  1 

Now  look  at  the  code  in  Figure  4-3  from  the  computer’s  perspective  —  read  only  one  line 
at  a  lime  and  do  not  refer  to  previously  read  lines.  The  computer  sees  the  variable 
counter  take  on  an  initial  value  of  50,  and  then  it  finds  a  for  .  .  I  oop  that  is  iterated 
50  times  during  the  first  execution  cycle  of  the  task  named  examp  I  e.  When  the  task  is 
scheduled  for  its  second  cycle,  counter  assumes  a  value  of  100  and  the  f or  .  .  I  oop  is 
now  executed  100  times.  Unfortunately  though,  the  computer  has  already  associated  a 
value  of  50  iterations  with  the  inner  loop  and  cannot  go  back  and  find  out  how  the  new 


value  of  counter  affects  previously  processed  code  in  subsequent  execution  cycles.  A 
simple  solution  to  this  problem  might  be  to  require  the  computer  to  remember  that  the 
variable  named  counter  affects  the  inner  loop  so  that  when  counter  changes,  a  new 
iteration  value  can  be  associated  with  the  inner  loop.  This  sounds  simple  until  one 
considers  that  the  value  of  counter  could  change  within  a  deeply  nested  procedure,  and 
the  attempt  to  follow  a  variable  into  and  out  of  a  nest  of  procedures  would  require  some 
very  complex  logic.  Such  a  process  borders  on  simulating  code  rather  than  performing  a 
static  analysis,  and  code  simulation  really  has  no  advantage  over  actual  code  execution. 
Another  solution  would  be  to  just  dismiss  single-line  processing  as  an  inadequate 
approach  because  of  such  a  shortfall,  but  before  doing  so,  consider  the  following 
example: 

task  body  example_t  is 
counter  :  natural; 
i  :  natura I ; 
beg  i  n 
I  oop 

counter  :*  temperature  (format  =>  keluin); 
for  i  in  1 . . counter  I oop 
end  loop; 

schedu  I  er .  uia  i  t_for_schedu  I  e ; 
end  loop; 
end  example_t; 

Figure  4-4,  Variable  Tracing  Example  #2 

The  example  in  Figure  4-4  illustrates  the  possibility  that  a  loop  control  variable  could  be 
determined  by  some  quantity  that  is  defined  only  at  run  time.  In  this  particular  case,  the 
variable  counter  is  a  function  of  the  temperature  measured  by  some  external  sensor. 
No  form  of  automated  analysis  can  properly  define  a  value  for  counter,  and  instances 
such  as  these  require  that  the  programmer  provide  some  extra  information  to  help  make  a 
static  code  analysis  effective.  Recall  that  the  AFTA  timing  analysis  is  interested  in  worst 
case  scenarios,  and  for  this  example  it  would  be  helpful  to  know  that  a  value  such  as  500 
is  a  reasonable  limit  on  the  value  of  counter.  Only  a  programmer  with  extensive 
knowledge  of  the  system  could  provide  such  input;  an  automated  analysis  tool  cannot  be 
expected  to  bridge  such  information  gaps. 


ft 

The  first  example  illustrates  a  situation  where  programmer  input  is  not  required 
but  serves  to  simplify  the  static  analysis  process,  while  the  second  example  demonstrates 
that  there  are  certain  situations  in  which  programmer  input  is  absolutely  necessary  to  ft 

make  the  static  analysis  effective.  If  the  programmer  uniformly  provides  information 
about  loop  iteration  maximums,  he  guards  against  the  analysis  roadblock  presented  by  the 
second  example  and  at  the  same  time  provides  a  simplified  solution  to  the  variable  tracing 
problem  of  Example  #1.  Situations  of  both  types  arise  during  a  static  code  analysis,  and  a  ft 

simple  request  that  the  programmer  provide  information  about  maximum  loop  iterations 
ultimately  makes  any  static  analysis  more  useful  and  actually  establishes  single-line 
processing  as  a  viable  approach. 

The  AFTA  timing  analysis  benefits  from  four  types  of  extraneous  information  that  ft 

the  programmer  should  be  able  to  provide.  They  are  as  follows: 

1.  What  is  the  maximum  number  of  iterations  in  a  for.. loop? 

2.  What  is  the  maximum  number  of  iterations  in  a  while.. loop? 

3.  What  is  the  maximum  number  of  bytes  in  a  message  passed  between  tasks?  I 

4.  What,  if  any,  is  the  maximum  number  of  iterations  for  a  basic  loop? 

This  information  must  be  provided  in  a  conventional  format  that  is  convenient  for 
the  programmer  to  understand  and  easy  for  the  analysis  tool  to  read.  The  most 
appropriate  method  to  communicate  such  data  is  through  comment  lines  within  the  source  I 

code.  These  are  the  rules  governing  the  use  of  comment  information: 

1.  The  information  must  be  conveyed  using  a  single  comment  line  which  begins 
with  the  standard  format. 

2.  This  is  followed  by  a  and  an  identifier  denoting  the  type  of  information.  I 

3.  Next  there  is  a  statement  of  the  form  “max=”  followed  by  a  base  10  integer  or 
the  word  “unde  f  i  ned”  for  infinite  loops  or  unknown  values. 

4.  The  comment  information  must  precede  the  corresponding  loop  or  message, 

although  it  does  not  have  to  be  placed  immediately  before  the  code  statement.  I 

5.  To  avoid  confusion  with  constructs  such  as  nested  loops,  information  relating 
to  an  inner  loop  must  fall  within  the  adjacent  outer  loop. 

6.  Refer  to  Figure  4-5  for  some  examples. 

The  concept  of  asking  for  extra  information  from  the  programmer  is  not 
unreasonable  or  uncommon.  In  [PARK90],  the  authors  describe  a  requirement  for  both 
maximum  and  minimum  loop  bounds  for  input  to  their  program  timing  tool.  Similarly, 

[PUSC89]  discusses  alterations  to  the  original  programming  language  for  the 
specification  of  loop  maximums  in  terms  of  an  iteration  count  or  a  time  delay.  The 
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comment  information  method  described  here  has  the  advantage  of  being  simple  to 
implement  and  flexible  with  regard  to  expansion.  Its  primary  disadvantage  is  that  there  is 
no  compiler  enforcement  of  this  convention.  The  programmer  is  free  to  omit  the 
information,  or  if  he  chooses  to  include  it,  he  might  use  an  improper  format. 


Figure  4-5,  Examples  of  Comment  Information 

4.3.2  Naming  Conventions 

Early  generation  programming  languages  like  FORTRAN  and  COBOL 
implement  global  naming  conventions  and  burden  the  programmer  with  name  space 
management.  When  naming  an  object,  the  programmer  is  forced  to  reference  name 
listings  to  ensure  that  the  name  is  used  in  the  proper  context  and  does  not  conflict  with 
any  other  name  in  the  system.  Ada  attempts  to  avoid  this  problem  through  the 
implementation  of  scope  rules  and  the  overloading  concept.  The  objective  is  for  code 
nesting  and  overloading  to  allow  programmers  to  pick  the  most  meaningful  and 
convenient  names  for  their  objects  without  being  concerned  about  the  use  of  the  same 
names  in  other  parts  of  the  system.  The  compiler  sorts  out  the  details  in  cases  of  name 
conflicts  and  thus  gives  the  programmer  a  great  deal  of  freedom.  Unfortunately,  the 
AFTA  timing  analysis  tool  is  not  as  smart  as  the  Ada  compiler,  and  it  is  necessary  to 
impose  a  few  simple  naming  conventions. 

The  first  convention  is  that  all  task  names  end  with  “_t  ”  when  used  to  define  the 
body  of  the  task.  The  analysis  tool  finds  the  task  names  in  the  task  specification  list  and 
automatically  appends  the  “_t  ”  when  searching  for  the  source  code  of  the  task  body.  If 
the  task  name  is  not  appended  in  this  manner,  its  source  code  will  not  be  found  and  will 
not  be  evaluated.  For  an  example  task  body  definition,  refer  back  to  Figure  4-3. 

The  second  convention  is  that  all  procedures  and  functions  defined  within  a  single 
task  must  have  unique  names.  The  reason  for  this  is  that  the  software  analysis  builds 
source  code  models  based  upon  procedure  calls,  and  a  specific  model  is  associated  with 
each  procedure  name.  If  a  task  makes  use  of  two  procedures  with  the  same  name,  the 
analysis  tool  will  be  confused  as  to  which  procedure  model  to  use.  Refer  to  Chapter  5  for 


—  *  for  loop:  max  =  100 

—  *  while  loop:  max  =  200 

—  *  message:  max  =  300 

—  *  basic  loop:  max  =  400 

—  *  basic  loop:  max  =  undefined 
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a  more  detailed  description  of  code  model  construction.  Ada  scope  rules  allow  the  same 

subprogram  name  to  be  used  for  multiple  procedures  or  functions  within  a  nested  code 

structure,  and  the  compiler  is  forced  to  figure  out  which  body  of  code  is  being  referenced  ft 

for  each  occurrence  of  the  name.  Likewise,  the  overloading  concept  permits  the 

programmer  to  use  identical  names  for  similar  functions  and  procedures,  provided  that  the 

compiler  can  distinguish  them  according  to  the  parameters  included  with  the  subprogram 

name.  The  logic  to  sort  such  details  is  quite  complex  and  is  not  included  in  the  AFTA  • 

software  analysis.  This  naming  convention  is  the  result  of  a  simple  engineering  tradeoff 

where  the  need  for  simplicity  in  the  analysis  tool  outweighs  subprogram  naming  freedom 

for  the  programmer. 

ft 

4.3.3  Undesirable  Constructs 

For  a  hard-real-time  system,  it  is  desirable  for  the  software  to  exhibit  a  predictable 
timing  behavior  so  that  task  scheduling  constraints  may  be  satisfied,  and  a  software 
timing  analysis  is  usually  interested  in  examining  worst  case  scenarios  to  ensure  that  I 

execution  timing  deadlines  are  always  met.  When  dealing  with  a  worst  case  scenario,  a 
static  code  analysis  can  be  easily  confused  by  certain  programming  constructs  and  thus 
provide  no  insight  into  their  timing  behavior.  In  practice,  such  constructs  may 
demonstrate  perfectly  acceptable  behavior,  but  they  have  a  tendency  to  cripple  the  » 

effectiveness  of  any  a  priori  analysis. 

One  undesirable  construct  for  real-time  software  involves  the  use  of  recursion.  As 
mentioned  previously,  the  AFTA  timing  analysis  builds  source  code  models  based  upon 
procedure  calls.  If  Procedure  A  calls  Procedure  B,  the  model  for  Procedure  B  is  inserted  I 

into  the  model  for  Procedure  A.  If  Procedure  A  calls  itself,  the  attempt  to  build  a  model 
for  Procedure  A  is  like  trying  to  sketch  the  reflection  of  one  mirror  appearing  in  another 
mirror.  Recursion  may  be  the  most  efficient  implementation  for  certain  algorithms,  but 
its  timing  behavior  is  usually  unpredictable  or  at  least  very  difficult  to  define.  The  AFTA  I 

software  analysis  notes  the  presence  of  recursive  constructs,  but  it  does  not  attempt  to 
model  them  or  analyze  them. 

As  with  traditional  recursion,  the  use  of  mutual  recursion  is  an  undesirable 
construct  for  real-time  software.  Mutual  recursion  refers  to  the  situation  where  Procedure  I 

A  calls  Procedure  B  and  Procedure  B  calls  Procedure  A.  The  problem  of  trying  to 
accurately  model  such  a  situation  is  similar  to  the  one  described  above,  and  the  AFTA 
software  analysis  notes  the  situation  but  does  not  attempt  to  analyze  such  a  construct. 

Another  dangerous  construct  involves  the  use  of  basic  loops  and  while  loops.  In  I 

order  for  the  timing  analysis  to  be  effective,  the  programmer  must  specify  the  maximum 
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number  of  iterations  for  each  instance  of  these  types  of  loops,  or  a  call  to  the 
wa  i  t_for_ schedu  I  e  procedure  must  be  included  inside  the  loop.  Even  if  a 
va  i  t_for_schedu  I  e  call  is  placed  inside  the  loop,  there  is  a  possibility  that  the 
timing  analysis  could  signal  the  presence  of  a  potential  infinite  loop.  Obviously,  an 
infinite  loop  is  an  unacceptable  possibility  for  a  real-time  task.  Figure  4-6  shows  an 
example  of  such  an  undesirable  situation. 


Notice  that  the  loop  shown  above  has  no  defined  maximum  iteration  count  but  does 
contain  a  call  to  u>a  i  t_f  or_schedu  I  e.  Thus,  one  might  assume  that  any  single 
execution  cycle  eventually  escapes  this  loop  by  reaching  the  u»ait_for -schedule 
call;  however,  the  software  analysis  looks  at  the  worst  case  scenario  only.  In  this  case,  it 
is  possible  that  the  u»a  i  t_for_schedu  I  e  call  is  never  reached,  and  an  infinite  loop  ties 
up  processing  resources  and  breaks  timing  deadlines.  The  AFTA  timing  analysis  notes 
this  situation  but  does  not  attempt  to  analyze  it. 


I  oop 

if  FLAP-STRTUS  =  FULL-UP  then 
compute (ALT  I TUDE, A I RSPEED) ; 
e  I  se 

scheduler,  uiai  t_f  or_schedu  1  e ; 
end  if; 
end  loop; 


Figure  4-6,  Potential  Infinite  Loop 
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Chapter  S 
Abstraction 


The  primary  challenge  of  the  software  analysis  is  to  identify  and  parameterize  the 
worst  case  execution  path  for  each  application  task.  An  execution  path  is  defined  to  be 
any  sequence  of  statements  encountered  between  two  successive  calls  to  the 
wa  i  t_for_3chedu  I  e  procedure;  thus  an  execution  path  determines  the  task’s  activity 
for  a  single  rate  group  frame.  In  order  to  identify  the  worst  case  path,  all  possible  paths 
must  be  explored,  and  a  valid  method  of  path  comparison  must  be  employed.  For  a  static 
analysis,  the  best  way  to  identify  execution  paths  is  to  model  the  flow  of  execution  for  a 
given  segment  of  source  code,  and  the  software  analysis  utilizes  the  concept  of 
abstraction  to  construct  such  flow  models  for  each  task  instantiation  in  the  task  suite. 
Abstraction  is  a  method  of  hiding  details  in  order  to  simplify  analysis,  and  it  is  ideal  for 
achieving  the  goals  of  the  AFTA  timing  analysis.  Recall  that  the  fundamental  assumption 
of  the  software  analysis  is  that  task  execution  time  can  be  accurately  modeled  according 
to  a  limited  set  of  known  functions;  abstraction  is  a  way  to  eliminate  details  and  highlight 
the  role  of  these  known  functions.  The  goal  of  abstraction  is  to  examine  the  task  source 
code  in  full  and  develop  a  model  that  preserves  only  the  information  necessary  for 
parameterizing  the  task  in  terms  of  known  deterministic  functions. 

5.1  The  Abstraction  Methodology 

The  process  of  building  source  code  models  is  rather  complex;  thus,  it  is  best  to 
begin  with  a  high  level  discussion  of  the  abstraction  methodology.  Task  source  code  is 
input  to  the  software  analysis  as  a  stream  of  characters  from  a  file.  These  characters  are 
assembled  into  single  lines  of  code,  and  the  code  lines  are  processed  individually  and 
sequentially.  In  the  context  of  this  analysis,  a  single  line  is  defined  as  that  which  falls 
between  successive  semicolons.  Abstraction  serves  as  a  filter  that  transforms  highly 
detailed  source  code  into  a  simplified  flow  model  for  execution  path  analysis.  As  each 
line  of  code  is  processed,  relevant  information  is  extracted  from  it,  and  the  code  itself  is 
then  discarded.  Information  that  is  considered  relevant  falls  into  two  categories:  flow 
control  items  and  known  deterministic  functions.  The  first  category  is  a  closed  set  of  Ada 
constructs  that  are  used  by  the  programmer  to  define  the  flow  of  task  execution.  These 
include  loop  constructs,  if-then-else  constructs,  case  statements,  and 
uia  i  t_for_schedu  I  e  calls.  The  second  category  is  an  open  set  of  functions  composed 
of  subprograms  whose  execution  delay  is  deterministic  and  has  been  measured  as  part  of 
AFTA  system  benchmarking  efforts.  Presently,  this  set  of  functions  primarily  consists  of 


operating  system  calls  and  in  particular,  message  passing  functions.  Figure  5- 1  shows  a 
full  list  of  the  critical  constructs  that  are  extracted  from  the  source  code  in  the  process  of 
model  construction. 
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Each  program  statement  is  searched  for  items  belonging  to  this  list.  When  a  critical 
construct  is  found,  it  is  appended  to  the  end  of  the  model  along  with  any  data  associated 
with  the  construct,  and  the  model  thus  becomes  a  reflection  of  the  task  source  code  with 
all  unnecessary  details  removed.  I 

5.2  The  Motivation  for  Abstraction 

Familiarity  with  the  abstraction  methodology  makes  it  is  easy  to  understand  the 
motivation  for  source  code  modeling  and  the  use  of  abstraction.  The  justification  for  this  ^ 

approach  to  software  analysis  is  best  summarized  as  follows: 

1.  The  use  of  code  models  expands  the  power  of  single-line  processing. 

Examining  program  statements  one  at  a  time  and  in  sequential  order  is  a  very 

restrictive  way  of  analyzing  source  code.  With  the  abstraction  method,  single  ^ 

line  processing  is  only  an  initial  stage  that  serves  to  build  the  task  model:  it  is 


I  oop 
exit 

for . . I oop 
uih  i  I  e  .  .  I  oop 
end  loop 
if.. then 
e  I  se 
end  i  f 
case . . when 
end  case 

scheduler. wait_f  or_schedu I e 
rg_commun  i  cat  i  on  .  queue_fnessage( ) 
rg_commun i cat i on . retr i eue_message( ) 
pg_commun i cat i on . 3end_message( ) 
rg_commun i cat i on . read_message( ) 
rg_ I og . rg_ I og_ent  ry ( ) 
debug_trace . debug_l og( ) 
rg_d i spatcher . io_ut i ls() 


Figure  5-1,  List  of  Critical  Constructs 
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not  responsible  for  code  analysis.  Thus,  any  static  analysis  limitations  of 
single-line  processing  disappear  once  the  model  is  built. 

2.  The  source  code  model  is  stored  as  a  collection  of  integers,  and  this  makes  it 
easy  to  analyze  and  manipulate  in  an  automated  fashion.  The  timing  analysis 
deals  only  with  the  task  model;  it  completely  ignores  the  original  source  code 
once  the  model  is  built.  This  allows  the  analysis  to  be  greatly  simplified 
because  it  is  not  wrapped  up  in  code  interpretation  or  string  manipulation,  and 
simplicity  is  vital  to  the  improvement  and  maintenance  of  the  analysis  tool. 

3.  The  task  model  is  constructed  in  a  format  that  is  ideal  for  identifying  and 
comparing  possible  execution  paths.  In  contrast,  examining  the  source  code 
itself  for  execution  paths  is  an  extremely  complex  task.  The  abstraction 
process  is  designed  specifically  to  transform  the  source  code  into  a  format  that 
allows  the  most  efficient  execution  path  identification,  parameterization,  and 
analysis. 

4.  Abstraction  serves  to  expose  the  message  passing  characteristics  of  an 
application  task  because  all  the  message  passing  procedures  are  included  in 
the  list  of  critical  constructs.  When  all  tasks  are  considered  simultaneously  in 
the  hardware  analysis  stage,  the  analysis  tool  develops  a  picture  of  worst  case 
global  message  passing  activity.  This  is  important  in  determining  the  timing 
behavior  of  the  rate  group  dispatcher,  which  is  executed  as  part  of  the  system 
overhead  in  every  minor  frame. 

5.3  Code  Model  Elements 

The  source  code  model  for  an  application  task  is  stored  as  a  collection  of  integers. 
Integer  manipulation  is  easily  accomplished  within  a  high  level  language  like  C;  thus  the 
format  of  the  model  lends  itself  to  a  simple  and  efficient  implementation  of  the  model 
analysis  procedures  discussed  in  Chapters  7  and  8.  The  model  is  a  one-dimensional  array 
of  entries,  and  each  entry  is  a  set  of  five  integer  elements.  These  elements  are  outlined 
below: 

1.  TYPE:  An  integer  value  representing  the  type  of  critical  construct  that  is 
found  in  the  source  code  and  recorded  as  a  model  entry.  Every  critical 
construct  listed  in  Figure  5-1  has  a  specific  integer  associated  with  it  and  is 
recognized  by  the  computer  according  to  its  numerical  value.  The  constant 
definitions  for  the  analysis  tool  are  found  in  “header.h,”  and  for  purposes  of 
code  readability  and  maintainability,  these  constants  are  referred  to  by  the 
names  listed  in  “header.h”  rather  than  their  respective  numerical  values. 


2.  VALUE:  Some  of  the  critical  constructs  have  a  value  associated  with  them, 
and  this  value  is  required  for  analyzing  worst  case  scenarios.  For  instance,  for 
all  loop  constructs,  the  VALUE  element  represents  the  maximum  number  of 
iterations  for  that  loop.  Loops  whose  behavior  is  undefined  are  assigned  one 
of  two  constant  values  whose  names  best  describe  the  nature  of  the  loop.  The 
names  of  these  constants  are  UNDEFINED  and  INFINITE;  their  meanings  are 
self-explanatory.  Message  passing  constructs  also  have  an  associated  value 
which  represents  the  maximum  size  of  a  message  in  64-byte  packets.  If  no 
maximum  value  is  specified  by  the  programmer,  the  message  passing 
limitations  listed  in  the  task  specification  file  (refer  to  Chapter  3)  are  used  as 
default  values. 

3.  DEPTH:  After  the  model  is  created,  each  entry  is  assigned  a  DEPTH  value  to 
represent  its  level  within  the  nested  structure  of  the  source  code.  The  DEPTH 
element  helps  the  model  emulate  the  modular  construction  of  the  original 
code,  and  the  information  conveyed  by  the  depth  element  is  vital  to  the  task  of 
identifying  possible  execution  paths. 

4.  POINTER:  Not  to  be  confused  with  a  pointer  in  C,  the  POINTER  element  is 
a  value  assigned  to  a  model  entry  after  the  model  is  fully  constructed.  It  is  the 
index  value  of  another  closely  associated  model  entry,  and  its  assigned  value 
is  essential  for  proper  identification  of  possible  execution  paths.  For  example, 
the  end  I  oop  construct  uses  the  POINTER  value  to  identify  the  index  for 
the  model  entry  that  represents  the  beginning  of  the  loop  construct.  The 
specific  rules  governing  the  assignment  of  the  POINTER  value  are  explained 
in  Chapter  7.  Not  all  model  entries  require  the  use  of  this  element  and  in  such 
cases,  the  POINTER  element  is  assigned  a  constant  value  named 
UNDEFINED. 

5.  FLOW:  This  element  is  used  only  during  the  generation  of  execution  paths 
through  the  code  model.  It  is  required  for  bookkeeping  purposes,  and  its  value 
assignment  conventions  are  discussed  in  Chapter  7. 

The  figures  on  the  following  page  illustrate  a  sample  model  construction.  Figure 
5-2  is  a  segment  of  test  code  designed  to  highlight  the  occurrence  of  critical  constructs;  it 
is  not  intended  to  represent  any  particular  algorithm.  Notice  in  the  parameter 
specifications  for  the  message  passing  procedures  that  only  the  fourth  parameter  is 
specified.  This  parameter  indicates  the  size  of  the  message;  the  other  parameters  are 
unimportant  to  the  timing  analysis  and  are  not  included.  It  is  important  to  understand  that 
the  source  code  lists  the  message  size  according  to  bytes  while  the  model  stores  the 
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I  OOP 

for  i  in  1 . . 20  I oop 

rg_commun  i  cat  i  on  .  queue-message  ( — ,  -  -,--,100,--,--); 
if  UflR-1  >  UflR-2 

rg—commun i cat  ion. queue-message ( --, 150,--,--); 
elsif  UflR_2  >  UflR_3 

rg_commun icat ion.retri eue_message( --, 175,--,--); 
else  URR-2  :=  0; 
end  i f ; 

scheduler. wai  t_for_schedu  I  e; 
end  loop; 

while  (URR_1  <  100)  loop 
UflR_1  :=  UflR_3  +  5; 
scheduler. wai t_f or_schedu I e ; 
end  loop; 

rg_commun i cat  ion. queue-message ( — , — , — ,200,--,--); 
end  loop; 


Figure  5-2,  Sample  Source  Code  Segment 
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Figure  5-3,  Sample  Source  Code  Model 


message  size  according  to  the  number  of  packets  since  all  analysis  calculations  deal  with 
packets  rather  than  bytes.  Figure  5-3  shows  the  code  model  that  is  constructed  from  the 
preceding  code  segment;  notice  that  the  flow  element  is  deliberately  left  unspecified  since 
it  is  only  used  during  execution  path  generation. 

The  model  follows  the  source  code  very  closely  since  the  code  is  primarily 
comprised  of  critical  constructs.  Each  occurrence  of  a  critical  construct  is  represented  by 
a  single  model  entry.  For  purposes  of  readability,  the  TYPE  element  is  listed  according 
to  the  name  of  the  appropriate  constant;  the  actual  constant  value  is  shown  in  parentheses. 
The  top  entry  indicates  an  infinite  loop,  which  is  followed  by  a  f  or  .  .  loop  with  a 
maximum  of  20  iterations.  The  queue-message  procedure  call  is  included  as  the  third 
model  entry,  and  the  message  size  (100  bytes/2  packets)  is  shown  in  the  VALUE  element. 
The  i  f  construct  in  entries  3  through  8  demonstrates  one  use  of  the  POINTER  element. 
When  a  conditional  statement  is  encountered  during  code  execution,  alternate  paths  may 
be  followed.  The  POINTER  value  indicates  where  execution  continues  if  a  given 
condition  is  not  satisfied.  For  example,  if  the  condition  associated  with  entry  #3  is  not 
met,  execution  continues  with  entry  #5,  and  if  the  condition  there  is  not  met,  execution 
continues  with  entry  #7.  The  POINTER  value  holds  the  key  to  following  the  proper  path. 
Notice  that  the  model  includes  no  information  about  what  conditions  are  imposed  by  the 
i  f  statement  in  entry  #3  or  the  e  I  a  i  f  statement  in  entry  #5.  The  timing  analysis  is  not 
intended  to  simulate  the  source  code;  rather,  its  intermediate  goal  is  to  find  all  possible 
execution  paths.  For  this  reason,  the  actual  test  condition  is  ignored;  it  is  only  important 
for  the  model  to  indicate  that  alternate  execution  paths  exist  due  to  the  presence  of  a 
conditional  statement.  Following  the  i  f-t  hen-e  I  ae  construct,  entry  #9  indicates  a  call 
to  ilia  i  t_f  or_achedu  I  e  (WFS);  a  WFS  call  marks  both  the  beginning  and  the  end  of 
any  execution  path.  Entries  #10,  #13,  and  #15  illustrate  the  use  of  the  POINTER  element 
to  link  the  end  of  a  loop  with  the  beginning  of  that  loop.  A  final  point  of  interest  for  this 
model  is  the  use  of  the  DEPTH  element  to  indicate  the  nesting  level  for  each  entry.  In 
Figure  5-2,  the  use  of  indentation  shows  the  logical  nesting  of  code  statements.  Likewise, 
the  value  of  the  DEPTH  parameter  in  Figure  5-3  carries  the  same  information.  For  any 
complete  subprogram  or  task,  the  DEPTH  value  begins  and  ends  at  zero,  and  each  level 
of  nesting  has  a  successively  greater  value. 

5.4  Bottom-Up  Construction 

The  power  of  high  level  languages  springs  from  the  use  of  modularity,  and  it  is 
essential  that  a  static  analysis  tool  is  able  to  recognize  and  properly  interpret  the  use  of 
procedures  and  functions  within  an  application  task  or  within  a  supporting  subprogram. 
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When  one  manually  performs  a  static  analysis  and  encounters  a  procedure  call,  it  should 
be  easy  to  find  the  code  for  that  procedure  and  examine  it  within  the  context  in  which  it  is 
called  upon;  however,  such  a  searching  task  is  not  so  trivial  for  an  automated  analysis 
tool.  For  an  automated  analysis,  when  a  procedure  call  is  found,  the  analysis  is 
suspended  while  the  compute,  searches  for  the  source  code  belonging  to  that  procedure. 
The  source  code  could  be  in  the  file  that  is  already  open  or  it  could  be  in  a  separate  file,  in 
which  case  two  or  more  files  are  simultaneously  left  open  for  examination.  The  problem 
grows  in  complexity  when  one  considers  the  possibility  that  the  first  procedure  coi»!d  call 
another  procedure  whose  source  code  resides  in  yet  another  file.  Of  course,  this  type  of 
procedure  nesting  can  go  on  for  many  levels  and  would  result  in  multiple  open  files  and 
multiple  suspensions  of  the  analysis  process.  Note  that  each  suspension  of  analysis 
results  in  a  complicated  effort  to  save  present  state  information  in  a  useful  format. 
Obviously  this  is  an  unwieldy  method  of  dealing  with  modular  source  code. 

The  use  of  a  source  code  model  avoids  the  problems  inherent  in  the  cyclical 
analyze  and  search  method  described  above.  The  tasks  of  processing  source  code  and 
analyzing  source  code  are  separated  through  the  use  of  the  code  model.  All  the  code 
processing  is  directed  toward  building  the  model  for  an  application  task,  and  then  the 
model  is  analyzed  independently  with  no  further  references  to  the  source  code.  In  order 
for  the  model  to  be  accurate  and  effective,  whenever  a  procedure  call  is  encountered,  the 
modeling  tool  must  already  know  the  name  and  nature  of  that  procedure  so  that  it  does 
not  have  to  search  for  its  source  code.  Thus,  the  source  code  model  must  be  constructed 
in  a  bottom-up  fashion  —  precisely  the  opposite  of  the  top-down  manner  in  which 
software  is  created.  In  other  words,  the  modeling  tool  begins  by  examining  the  most 
elemental  procedures  and  progresses  upward  to  higher  level  procedures,  which  often  call 
upon  the  more  elemental  procedures.  Figure  5-4  illustrates  this  concept. 
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Figure  5-4,  An  Ideal  Software  Hierarchy 
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This  type  of  bottom-up  model  development  depends  upon  an  understanding  of  the 
program  unit  linking  mechanisms  employed  by  Ada.  An  Ada  compilation  unit  is  defined 
as  the  specification  or  the  body  of  a  program  unit,  which  can  be  compiled  as  independent 
text;  the  body  of  an  application  task  is  one  example  of  a  compilation  unit.  It  may  be 
preceded  by  a  context  clause  that  identifies  other  compilation  units  upon  which  it 
depends,  and  the  context  clause  uses  with  statements  to  name  the  supporting  program 
units  [B0087].  In  general,  the  package  containing  a  task  body  begins  with  a  context 
clause  that  indicates  which  packages  contain  subprograms  utilized  by  the  task  body,  and 
this  is  the  key  to  identifying  the  particular  hierarchical  structure  of  a  task.  A  package 
referenced  by  the  task’s  context  clause  may  have  its  own  context  clause  for  the 
subprograms  upon  which  it  depends.  Thus,  an  examination  of  all  relevant  context  clauses 
reveals  the  task’s  dependency  relationships  and  enables  the  model  building  process  to 
begin  at  the  bottom  of  the  pyramid  as  shown  in  the  preceding  figure.  Chapter  6  explores 
the  procedure  by  which  the  software  hierarchy  of  an  application  task  is  exposed  and 
utilized  during  the  modeling  process. 

5.5  Expandability 

A  key  feature  of  the  abstraction  approach  is  the  ability  to  later  expand  upon  the 
code  models  that  are  generated  and  thus  improve  the  results  of  the  liming  analysis. 
Current  benchmarking  efforts  for  the  AFTA  [CLAS93]  are  aimed  at  quantifying 
operating  system  overhead,  and  it  is  for  this  reason  that  the  critical  constructs  list  (Figure 
5-1)  is  primarily  composed  of  operating  system  calls.  As  the  project  progresses,  system 
benchmarking  will  determine  the  execution  delay  for  many  more  functions  that  could  be 
used  by  the  operating  system  and/or  the  application  tasks.  Once  a  function  is  measured,  it 
will  be  added  to  the  list  of  critical  constructs,  and  its  delay  will  be  accounted  for  in  the 
hardware  modeling  stage  of  the  analy  s.  The  timing  analysis  software  is  written  in  such 
a  manner  as  to  facilitate  the  addition  of  cn  ical  constructs  to  the  system  model,  for  there 
are  a  limited  number  of  procedures  attested  by  such  an  addition.  Appendix  G  outlines 
the  specific  steps  that  should  be  taken  to  update  the  timing  analysis  software  for 
additional  critical  constructs. 
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Chapter  6 

Source  Code  Processing 


The  software  analysis  stage  is  divided  into  two  phases:  source  code  processing 
and  task  model  analysis.  The  goal  of  the  source  codv*  processing  is  to  build  a  complete 
and  accurate  model  of  the  application  task  source  code.  Once  the  model  is  developed,  the 
source  code  is  no  longer  needed,  and  the  task  model  alone  is  presented  for  further 
analysis. 

The  primary  objectives  of  source  code  processing  are  defined  as  follows: 

1.  To  understand  the  program  unit  hierarchy  for  each  application  task  and  to 
know  where  to  find  every  relevant  unit  of  source  code. 

2.  To  properly  interpret  program  statements  and  understand  modular  code 
construction  regardless  of  any  specific  programming  style  in  use. 

3.  To  extract  relevant  information  in  an  orderly  manner,  store  it  in  an  efficient 
format,  and  apply  it  to  task  model  development. 

6.1  The  Big  Picture 

An  explanation  of  the  execution  flow  for  source  code  processing  is  rather  tedious, 
and  it  is  helpful  to  first  understand  the  basic  structure  of  the  timing  analysis  software.  On 
the  following  page.  Figure  6-1  illustrates  the  hierarchy  of  procedures  used  in  both  the 
software  and  hardware  analysis.  Notice  in  this  diagram  that  subordinate  procedures  are 
physically  linked  to  their  parent  procedure(s);  these  links  should  help  demonstrate  the 
context  in  which  each  procedure  is  called.  The  source  code  for  all  procedures  shown  is 
listed  in  FINISH.C  and  is  included  in  Appendix  D. 

The  source  code  processing  progresses  on  a  task  by  task  basis,  and  the  procedure 
called  task-parse  is  primarily  responsible  for  the  model  development  of  individual 
tasks,  task_parse  is  called  from  process-l  i  st,  and  it  is  passed  the  name  of  a 
single  task  and  the  name  of  the  file  in  which  the  task  body  is  defined.  Notice  that 
task-parse  is  a  pivotal  node  in  the  analysis  hierarchy  and  essentially  orchestrates  all 
the  activities  associated  with  the  software  analysis.  When  t  ask_parse  is  complete,  it 
passes  control  back  to  process- 1  ist  and  also  returns  a  parameterized  representation 
of  the  original  task. 

5.2  Establishing  the  Hierarchy 

The  code  processing  begins  with  the  development  of  the  task’s  program  unit 
hierarchy,  and  this  is  achieved  by  the  procedure  called  f  i  nd_packages.  As  Chapter  5 
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explains,  application  task  software  is  typically  organized  according  to  package  units 
whose  names  are  specified  in  context  clauses,  f  i  rtd_packages  is  given  the  filename  of 
the  package  containing  a  given  task  (as  specified  during  preliminary  processing),  and  it 
compiles  a  list  of  all  packages  containing  subprograms  used  by  that  task  and  its 
supporting  subprograms.  This  list  is  an  array  of  filenames  stored  in  a  structure  called 

p k g _ I  ist.  The  procedure  update_pkg_l  i  3 1  does  most  of  the  work  for 

f  i  nd-packages.  It  is  given  a  filename  and  opens  that  file  to  search  for  the  uuith 
statements  of  the  file’s  context  clause.  For  each  uiith  statement,  it  uses  the  procedure 
called  w  i  th_f  ound  to  extract  the  name  of  the  associated  program  unit  and  then  adds 
that  name  to  the  end  of  pkg_  I  i  st ,  if  it  is  not  already  present.  The  first  time 
f  i  nd-packages  calls  update_pkg_l  i  st,  it  sends  in  the  name  of  the  file  containing 
the  application  task,  and  this  begins  the  construction  of  pkg_  I  i  st .  On  subsequent  calls, 

f  i  nd_ packages  extracts  package  names  from  p k g _ I  i  st  and  converts  them  to 

filenames  to  be  passed  to  updat  e_pkg_  I  i  st  for  processing.  This  process  continues 

until  the  context  clause  for  every  entry  in  p k g _ list  is  examined.  In  this  way,  all 

subprogram  dependencies  are  explored  in  such  a  manner  that  the  program  units  at  the  top 
of  pkg_  I  i  st  are  supported  by  the  units  found  further  down  the  list.  No  program  unit 
should  depend  upon  a  unit  that  appears  above  it  in  the  final  package  list. 

6.3  Code  Modeling  Tools 

Once  pkg_l  ist  is  fully  constructed,  the  actual  code  modeling  begins, 
task-panse  starts  by  examining  the  units  at  the  bottom  of  the  list  so  that  models  are 
first  developed  for  the  most  elemental  procedures  and  functions.  For  each  entry  in 
pkg_l  ist,  task-parse  utilizes  the  procedure  called  parse  to  perform  the  code 
examination  and  model  construction.  After  each  subprogram  is  modeled,  any  pertinent 
information  is  stored  in  a  data  structure  called  procedures.  As  the  modeling  process 
progresses,  calls  to  previously  modeled  subprograms  are  encountered,  and  when  this 
occurs,  the  model  for  the  subordinate  subprogram  is  inserted  directly  into  the  growing 
model  of  the  parent  subprogram.  Once  each  package  unit  in  pkg_  I  ist  is  processed  by 
parse,  the  package  containing  the  task  body  is  sent  to  parse  so  that  a  complete  model 
of  the  task  is  developed  for  later  analysis. 

6.3.1  parse 

The  parse  procedure  is  a  generic  unit  designed  to  process  any  type  of  source 
code,  whether  it  belongs  to  a  package,  a  subprogram,  or  an  application  task.  It  is  used  by 
task-parse  as  a  black  box  processing  tool  that  directs  the  low  level  parsing  activity  of 
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bottom-up  task  model  development.  The  algorithm  employed  by  parse  is  a  simple 
iterative  process  as  is  shown  on  the  following  page  in  the  flow  diagram  of  Figure  6-2. 
Basically  this  procedure  opens  a  designated  file,  grabs  individual  program  statements 
with  a  procedure  called  get_l  i  ne,  and  examines  them  with  a  procedure  called 
search.  The  parsing  process  ends  when  any  one  of  three  conditions  is  satisfied.  These 
conditions  are  as  follows: 

1.  A  fatal  processing  error  occurs. 

2.  The  task  model  is  complete. 

3.  The  end  of  the  file  is  reached. 

The  inputs  to  parse  describe  the  context  in  which  the  code  processing  is  taking  place, 
and  these  include  items  such  as  the  name  of  the  current  task,  the  name  of  the  file  to  be 
opened,  the  name  of  the  package  being  parsed,  and  the  message  passing  default  values  for 
the  current  task.  The  outputs  from  parse  include  an  updated  version  of  the  procedures 
data  structure,  and  if  the  task  body  itself  is  submitted  to  parse ,  the  procedure  outputs  a 
complete  model  of  that  task.  The  operation  of  parse  depends  upon  three  key 
procedures:  read— I  ist,get_l  i  ne,  and  search. 

6.3.2  read- 1  I  st 

One  of  the  initial  functions  of  process- I  i  3 1  is  to  call  read- I  isl  in 
preparation  for  the  parsing  activity  to  follow,  read- 1  i  st  is  designed  to  read  a  pre¬ 
defined  file  called  key_utords  .  dat  and  extract  from  that  file  a  list  of  key  terms  that  act 
as  a  guide  to  interpreting  source  code.  The  list  is  stored  as  an  array  of  string  variables  in 
a  structure  called  search- 1  i  st.  Also  stored  in  search- I  i  3t  is  an  integer  called 
I  ength  to  specify  the  number  of  items  found  in  key_uiord3  .  dat.  This  version  of 
read— I  i  st  is  identical  to  the  one  described  in  Chapter  3,  Preliminary  Processing.  The 
search— I  i  st  structure  really  could  be  hard-wired  into  the  timing  analysis  source  code, 
but  the  use  of  read- 1  i  st  encourages  code  modularity  and  maintainability  since  the  list 
of  key  terms  can  be  altered  without  changing  the  source  code  for  the  analysis  tool  and 
forcing  a  recompilation. 

6.3.3  get- 1  I  ne 

The  purpose  of  get- 1  i  ne  is  to  pull  individual  characters  from  a  specified  input 
file  and  construct  a  single  program  statement  that  is  stored  in  a  structure  called 
t  h  i  s_  I  i  ne.  t  h  i  s_  I  i  ne  is  formatted  as  an  array  of  string  variables  with  each  string 
representing  a  single  word  within  the  program  statement.  It  also  has  an  integer  called 
length  to  describe  the  number  of  words  in  the  program  statement  and  an  integer  called 
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Figure  6-2,  The  parse  Algorithm 
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marker,  which  can  act  as  a  pointer  to  a  specific  word  of  the  program  statement  when 

t  h  i  s_ I  i  ne  is  passed  between  procedures.  One  function  of  get_  I  i  ne  is  to  eliminate 

all  white  space  and  unnecessary  comments  from  the  source  code  and  reduce  a  code  * 

segment  to  an  unformatted  series  of  program  statements.  The  removal  of  indentation 

formatting  from  the  code  forces  the  code  processing  to  ignore  that  aspect  of  programmer 

style,  get  - 1  i  ne  also  reduces  all  upper  case  characters  to  lower  case  characters  as  they 

are  read  from  the  input  file;  this  makes  the  source  code  processing  case  independent  and  * 

removes  yet  another  element  of  programmer  style. 

6.3.4  search 

A  procedure  named  search  is  responsible  for  finding  and  extracting  important  ► 

information  from  the  individual  program  statements,  and  it  simultaneously  directs  the 
development  of  the  current  code  model.  See  Figure  6-3  on  the  following  page  for  a  flow 
diagram  of  search.  The  current  code  model  is  stored  in  a  structure  called  skeleton 
(since  it  is  a  bare  bones  representation  of  the  source  code).  Both  search- 1  ist  and  ft 

th  i  3_ I  i  ne  are  inputs  to  search,  and  for  each  program  statement,  this  procedure 
compares  every  word  to  every  entry  in  search- list.  When  an  exact  match  is  found, 
the  current  code  model  is  usually  updated,  and  part  of  the  update  may  require  that 
additional  information  is  extracted  from  the  program  statement  or  from  other  data  ft 

sources.  For  instance,  if  a  message  passing  call  is  found,  search  activates  a  procedure 
called  f  i  nd_paramet  er  in  order  to  determine  the  maximum  size  of  the  message 
involved.  Likewise,  for  any  looping  construct  that  is  found,  search  uses  a  procedure 
called  process— I  oop  to  determine  the  type  of  loop  and  the  maximum  number  of  ft 

iterations  associated  with  that  loop,  search  is  essentially  a  grand  3w  i  t  ch  statement 
with  a  single  case  entry  corresponding  to  each  item  in  3earch_  list.  The  use  of  the 
switch  statement  allows  the  overall  comparison  process  to  remain  generic  while 
preserving  the  uniqueness  of  response  for  matches  with  various  items  in  search- list.  ft 

Keep  in  mind  that  the  code  processing  algorithm  is  intended  to  be  as  generic  as 
possible  so  that  the  parse  procedure  can  be  used  to  deal  with  any  segment  of  code, 
whether  it  belongs  to  a  task,  a  package,  a  procedure,  or  a  function.  This  approach  does 
involve  a  simple  tradeoff,  however.  The  advantage  is  that  only  one  set  of  searching  ft 

procedures  is  written,  tested,  and  maintained.  The  disadvantage  is  that  the  code 
examination  process  must  be  flexible  enough  to  handle  all  situations  and  intelligent 
enough  to  recognize  the  source  code  from  different  types  of  program  units.  In  other 
words,  there  is  no  master  procedure  that  recognizes  what  type  of  code  is  being  processed  ft 

and  selects  the  appropriate  searching  procedure;  rather,  all  the  processing  decisions  are 
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made  at  a  low  level  as  the  search  progresses.  One  consequence  of  this  approach  is  that 
some  overhead  state  information  must  be  carried  in  and  out  of  the  search  procedure 
through  the  passing  of  pointers  in  the  parameter  list.  This  information  is  needed  by 
search  in  order  to  understand  the  context  in  which  the  current  program  statement  is 
written.  Every  time  search  is  called,  it  receives  a  single  program  statement  along  with 
pointers  to  information  about  the  state  of  the  current  search  process.  The  search 
procedure  continuously  gathers  and  maintains  this  state  information  to  enable  it  to 
understand  program  statements  that  it  will  have  to  examine  in  the  future. 

Two  variables  that  hold  state  information  are  strings  called  ta3k_name  and 
pkg_name.  Recall  that  task_parse  processes  code  in  two  stages:  the  first  stage 
examines  and  models  all  supporting  subprograms  and  the  second  stage  examines  and 
models  the  task  code  itself.  The  task  name  is  needed  only  in  the  second  stage  when  the 
task  code  itself  is  being  processed;  otherwise,  it  is  defined  as  “none.”  This  differentiation 
alone  tells  parse  whether  it  is  dealing  with  task  code  or  supporting  subprogram  code. 
The  reason  the  name  is  necessary  for  task  processing  is  that  the  source  code  for  several 
tasks  may  be  included  within  the  same  file,  though  tasks  are  analyzed  only  on  an 
individual  basis.  Preliminary  processing  identifies  the  file  containing  a  particular  task, 
and  when  it  is  time  to  process  that  task,  the  appropriate  file  is  opened.  If  there  are 
multiple  tasks  within  that  file,  the  source  code  processing  is  applied  only  to  the  specified 
task;  other  source  code  is  ignored.  The  only  way  that  the  code  processing  algorithm 
knows  which  code  to  examine  and  which  code  to  ignore  is  if  it  can  find  the  begin  and 
end  statements  for  the  specified  task.  The  begin  statement  always  contains  the  task 
name,  and  the  end  statement  typically  uses  the  task  name  as  well,  although  it  is  not 
required.  Refer  back  to  Figure  4-2  for  a  specific  example.  Thus  the  task_name 
variable  is  used  by  the  code  processing  algorithm  as  a  guide  to  determine  where  the  task 
body  definition  is  located  within  the  file  that  is  currently  being  examined.  If  task_name 
is  defined  as  “none,”  parse  knows  to  process  all  source  code  and  not  to  search  for  only 
the  executable  code  of  the  task  body. 

The  variable  called  pkg_name  is  needed  for  proper  identification  of 
subprograms.  Once  a  procedure  or  function  is  examined  and  modeled,  its  model  is  stored 
in  the  structure  called  procedures,  and  a  name  is  associated  with  it  for  identification 
purposes.  When  a  subprogram  is  called  from  outside  of  the  package  within  which  it  is 
defined,  the  appropriate  package  name  precedes  the  name  of  the  subprogram.  For 
example,  the  procedure  id  a  i  t_f  or_schedu  I  e  is  defined  within  the  package  called 
scheduler,  and  a  call  to  this  procedure  from  the  task  body  uses  the  name 
schedu  I  er  .  i«a  i  t_f  or_schedu  I  e.  Thus,  for  every  subprogram  model,  the  name  is 
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stored  in  the  “package_name.subprogram_name”  format  so  that  when  the  subprogram 
call  is  encountered  by  search,  the  contents  of  the  program  statement  exactly  match  the 
name  of  the  model  stored  in  procedures. 

The  name  of  the  file  currently  being  processed  is  also  passed  to  the  search 
procedure,  and  this  is  necessary  for  error  tracking.  When  a  critical  error  occurs  in  the 
model  building  process,  the  package  name,  procedure  name,  and  filename  are  all  included 
in  the  message  recorded  in  the  error  file.  Such  error  tracking  is  particularly  helpful  in 
developing  and  testing  the  timing  analysis  program,  but  it  should  also  be  helpful  to  the 
user  in  finding  and  correcting  any  undesirable  constructs  that  are  detected  in  the  course  of 
the  timing  analysis. 

Also  included  in  the  parameter  list  of  search  is  a  pointer  to  the  structure  called 
end— I  i  st.  This  is  a  one  dimensional  array  of  strings  that  is  useful  in  tracking  the 
nesting  structure  of  the  source  code.  Ada  syntax  requires  that  many  constructs  conclude 
with  an  end  statement,  and  a  list  of  these  constructs  is  included  below: 


name] ; 
fund  i 
I  oop .  . 
if..., 
case .  . 
recorc 
beg i n . 


.  end 

[package  name]; 

.  end 

[task  name]; 

.  end 

[procedure 

.  end 

[  fund  i  on  name] ; 

.  end 

1  oop ; 

.  end 

i  f ; 

.  end 

case ; 

.  end 

record; 

.  end 

[block  name]; 

.  end 

select; 

Figure  6-4,  Ada’s  Framed  Constructs 


The  ability  to  properly  interpret  a  given  program  statement  often  depends  upon 
knowledge  of  previous  program  statements,  and  this  is  particularly  true  when  dealing 
with  end  statements.  The  maintenance  of  the  end- I  i  st  structure  gives  the  code 
processing  tools  critical  information  about  the  context  in  which  a  specific  program 
statement  is  written,  and  it  also  helps  keep  track  of  the  nested  structure  of  the  source 
code.  Whenever  the  beginning  of  a  framed  construct  is  detected,  a  corresponding  string 
entry  is  added  to  the  tail  of  end- 1  i  st.  Then,  when  an  end  statement  is  encountered,  it 
is  compared  with  the  last  entry  in  end-  list,  and  the  two  strings  should  match.  If  they 

61 


I 


k 


> 


» 


» 


i 


» 


» 


> 


> 


> 


fl 


> 


do  not  match,  a  processing  error  has  occurred  and  is  properly  noted  in  the  error  file.  For 

instance,  if  the  beginning  of  a  loop  is  found,  the  string  “end  I  oop”  is  appended  to 

end- 1  i  st,  and  the  code  processing  tools  then  know  to  expect  that  the  next  end  I 

statement  encountered  will  be  an  “end  loop.”  This  seems  to  be  quite  trivial  for 

statements  like  “end  i  f,  end  loop,  end  case,”  and  “end  3e  I  ect”  because  the 

program  statement  explicitly  defines  the  type  of  construct  to  which  the  end  statement 

belongs.  However  this  tracking  process  is  absolutely  necessary  for  the  other  constructs  » 

whose  end  statements  remain  rather  vague.  The  end  statements  for  packages,  tasks, 

procedures,  functions,  and  block  statements  do  not  have  to  include  the  name  of  the 

construct,  though  many  programmers  prefer  to  include  the  name  for  code  readability  and 

debugging  purposes.  When  the  code  processing  tools  encounter  a  non-specific  end  I 

statement  (with  no  name  included),  there  is  no  way  to  determine  what  program  unit  or 

construct  is  affected,  but  by  checking  the  last  entry  in  end _ I  i  3t,  it  is  easy  to  interpret 

the  meaning  and  significance  of  the  end  statement.  This  is  illustrated  in  the  following 

example:  I 


package  body  ambiguous  is 
task  body  example_t  i3 
procedure  compute  is 
beg  i  n 

end; 
beg  i  n 

end ; 
end ; 


Figure  6-5,  Example  of  end  Statement  Ambiguity  I 

After  processing  the  first  three  program  statements  shown  in  Figure  6-5,  the 
end_l  i  st  data  structure  has  the  following  three  entries:  “end  amb  i  guou3,  end 
examp  I  e_t ,  end  compute.”  When  the  first  end  statement  is  found,  the  analysis  I 

program  is  uncertain  whether  that  statement  belongs  to  the  package,  the  task,  or  the 
procedure,  but  after  referring  to  the  last  entry  in  end- I  i  st,  it  finds  that  the  end 
statement  belongs  to  a  construct  called  comput  e.  The  strings  called  pkg_name  and 
task-name  hold  the  names  of  the  current  package  and  task,  and  the  structure  called  I 

procedures  holds  the  name  of  the  current  procedure.  The  states  of  these  variables  are 
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checked  to  find  out  that  compute  is  the  name  of  the  current  procedure.  This  is  valuable 
information  since  it  indicates  that  code  processing  is  complete  for  the  procedure  called 
compute,  and  its  model  is  ready  to  be  sent  to  the  model  reduction  tools  (Chapter  7)  for 
final  processing.  Once  the  first  end  statement  is  properly  deciphered,  last  entry  in 
end_l  i  at  is  eliminated,  and  two  entries  remain.  The  interpretation  process  is  similar 
for  the  next  two  end  statements,  and  when  processing  is  complete  for  the  code  segment 
of  Figure  6-5,  end_l  i  at  is  left  empty  since  the  code  processing  properly  works  its  way 
into  and  back  out  of  the  nested  source  code.  If  end_  I  i  st  is  not  empty  when  the  end  of 
a  file  is  found,  a  fatal  error  has  occurred  and  is  so  noted  in  the  error  file. 

Yet  another  useful  state  variable  needed  within  the  search  procedure  is  a 
structure  called  flags.  This  is  a  set  of  five  boolean  variables  used  to  maintain  and 
transfer  status  information  during  code  processing.  Each  of  the  flags  performs  a 
necessary  function  although  the  types  of  functions  vary  widely.  The  set  as  a  whole  is 
actually  an  ad  hoc  compilation  of  status  variables  that  is  assembled  to  make  it  easy  to 
pass  different  types  of  information  between  procedures  under  a  single  pointer  name.  All 
flags  are  initialized  to  a  value  of  “no”  at  the  beginning  of  the  source  code  processing  for 
each  task,  and  the  current  values  of  the  flags  help  the  analysis  program  to  make  critical 
decisions  about  code  processing  and  model  development.  What  follows  is  a  detailed 
description  of  the  function  of  each  of  the  five  flags. 

1.  mode  I  _act  i  oe:  The  executable  code  for  a  program  unit  generally  follows 
some  declarative  statements  such  as  variable  definitions.  There  is  no  need  to 
include  these  declarative  statements  in  the  model  building  process,  and  the 
model  is  considered  to  be  inactive  until  the  executable  code  is  encountered. 

The  executable  code  is  bound  by  begin  and  end  statements,  and  when  the 
begin  statement  is  found,  model_actioe  is  given  a  “yes ”  value. 
Likewise,  when  the  end  statement  is  found,  model  _a  cl  iue  is  given  a  “no” 
value. 

2.  task_found:  A  file  may  contain  more  than  one  task  body  definition.  It  is 
therefore  useful  to  know  when  the  code  for  a  specific  task  body  is  found  so 
that  code  from  other  task  bodies  does  not  improperly  contribute  to  the  current 
task  model.  Once  the  statement  “task  body  [name]  i  s  ...”  is  found, 
the  t  ask_f  ound  flag  registers  a  “yes”  value.  When  the  end  statement  for 
the  task  is  encountered,  task_f  ound  returns  to  its  initial  “no”  value.  Note 
that  the  mode  I _ac t  i  ue  flag  is  dependent  upon  the  task_found  flag 
during  parsing  of  the  file  containing  the  task  body  definition.  The 
model  _act  iue  flag  cannot  register  a  “yes”  value  until  the  i  ask_f  ound 
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flag  indicates  a  “yea”  value;  thus  the  model  building  process  begins  only  after 
the  executable  code  for  the  appropriate  task  is  located. 

3.  pkg_f  ound:  The  software  hierarchy  for  an  application  task  is  developed  as  a 
series  of  package  names  that  are  found  within  context  clauses.  The  source 
code  processing  e\amines  each  package  in  succession  while  progressing 
upwards  from  the  bottom  of  the  package  list.  When  search  encounters  the 
beginning  of  the  specified  package  body,  it  sets  pkg_  found  to  a  value  of 
“yes,”  and  it  likewise  deactivates  the  flag  when  it  encounters  the  end  of  the 
package.  Neither  the  task_found  flag  nor  model— act  i  ue  flag  can  be 
activated  unless  the  pkg_f  ound  flag  is  already  activated. 

4.  finished:  A  single  file  may  contain  several  task  body  definitions,  but  tasks 
are  processed  on  an  individual  basis.  Therefore,  it  is  reasonable  for  the 
software  analysis  to  discontinue  file  parsing  once  the  appropriate  task  body  is 
examined  and  modeled.  When  the  task  body’s  end  statement  is  encountered, 
the  f  i  n  i  shed  flag  is  set  to  “yes,”  and  this  leads  to  an  exit  from  the  parsing 
loop. 

5.  fatal_error:  A  fatal  error  occurs  when  the  end- 1  i  3t  construction 
encounters  a  mismatch.  In  other  words,  the  source  code  processing  might 
expect  to  find  the  end  statement  for  a  procedure  but  instead  finds  a  statement 
like  “end  i  f .”  Such  an  error  indicates  an  interpretation  mistake  or  oversight 
by  the  source  code  processing,  and  the  current  code  model  is  labeled  as 
invalid.  This  type  of  error  undermines  the  effectiveness  of  the  modeling  and 
analysis  for  a  given  task  because  it  indicates  that  part  of  the  task  model  is 
incorrect,  and  thus  the  entire  model  cannot  be  trusted  to  produce  accurate 
results.  Fatal  errors  also  disrupt  the  analysis  for  the  entire  system,  since  the 
system  is  analyzed  as  a  simple  collection  of  tasks.  When  the  f  at  a  I  —error 
flag  is  set  to  “yes,”  code  processing  is  halted  for  the  current  task,  and  the 
software  analysis  proceeds  to  the  next  task.  The  conditions  causing  the  error 
are  noted  in  the  error  file,  and  the  final  system  analysis  ignores  any  tasks  that 
fall  subject  to  a  fatal  error.  It  is  not  necessary  to  halt  the  entire  system  analysis 
because  of  errors  experienced  with  an  individual  task,  but  the  user  must  be 
aware  that  the  system  results  produced  are  actually  incomplete.  In  such  cases, 
the  user  is  responsible  for  focusing  on  the  results  of  individual  task  analyses 
rather  than  depending  upon  the  conclusions  from  the  full  system  analysis. 
Certainly,  some  of  the  lower  level  results  are  useful,  and  it  is  for  this  reason 
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that  errors  in  a  single  task  model  are  not  allowed  to  halt  analysis  for  the  rest  of 
the  system. 

The  final  item  in  the  parameter  list  for  search  is  a  pointer  to  a  structure  called 
procedures.  This  data  structure  holds  a  collection  of  subprogram  models  that  are 
developed  during  the  bottom-up  task  model  construction,  procedures  is  organized  as 
a  list  of  entries  with  each  entry  corresponding  to  a  unique  subprogram.  An  individual 
entry  holds  the  name,  filename,  and  code  model  description  for  a  single  procedure  or 
function.  Whenever  code  processing  and  model  reduction  are  completed  for  a 
subprogram  unit,  the  appropriate  data  is  added  to  the  list  held  in  procedures.  During 
the  search  process,  every  program  statement  is  examined  to  see  if  it  contains  a  call  to  one 
of  the  subprograms  that  has  been  modeled  and  is  presently  stored  in  procedures.  If 
such  a  call  is  found,  the  model  for  the  subprogram  is  inserted  directly  into  the  current 
code  model.  This  is  the  method  by  which  code  modularity  is  recognized,  exposed,  and 
captured  in  the  course  of  task  model  development. 

As  mentioned  previously,  search  is  essentially  a  grand  switch  statement  which 
triggers  specific  responses  for  each  of  the  critical  constructs  that  might  occur  within  a 
given  program  statement.  The  following  paragraphs  briefly  describe  the  actions  taken 
when  dealing  with  the  various  types  of  critical  constructs.  The  boldface  word  at  the 
beginning  of  each  paragraph  corresponds  to  the  name  of  the  identifying  constant  used 
with  each  construct. 

WFS:  When  a  call  to  uia  i  t_for_3chedu  I  e  is  found,  a  WFS  entry  is  simply 
added  to  the  current  code  model,  provided  that  the  mode  I  _act  i  ue  flag  indicates  a 
“ye 3”  value.  No  further  action  is  necessary. 

LOOP:  There  are  four  different  types  of  Ada  program  statements  that  could 
contain  an  instance  of  the  word  “loop.”  These  are  listed  below: 

1.  end  I  oop 

2.  uih  i  I  e .  .  I  oop 

3.  for  .  .  I  oop 

4.  I  oop  (basic) 

The  search  procedure  is  responsible  for  differentiating  between  these  possibilities  and 
updating  the  current  model  appropriately.  The  test  for  an  “end  I  oop”  statement 

requires  a  simple  examination  of  the  program  statement  stored  in  this _ I  i  n  e .  If  an 

“end  I  oop”  is  found,  no  action  is  taken  because  the  presence  of  the  word  “end"  will 
have  already  triggered  all  the  necessary  processes  during  a  previous  iteration  of  the 
search  loop.  The  remaining  three  possibilities  signal  the  beginning  of  a  loop  construct. 
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and  it  is  important  for  search  to  identify  the  type  of  loop  and  its  iteration  limitations. 
For  this  purpose,  a  procedure  called  process,  loop  is  called,  and  its  job  is  to  scan  the 
program  statement  to  determine  what  type  of  loop  is  being  used,  process,  loop 
utilizes  yet  another  procedure  called  target.found  that  searches  the  program 
statement  in  reverse  to  find  out  if  a  “uih  i  I  e”  or  a  “for”  precedes  the  occurrence  of  the 
word  “loop.”  The  results  of  this  search  determine  what  type  of  loop  to  add  to  tie  code 
model,  and  the  value  element  of  the  loop  entry  is  determined  in  one  of  two  ways.  The 
first  method  is  to  use  the  comment  information  preceding  the  loop  statement.  If  no 
comment  information  is  provided,  the  value  element  is  recorded  as  UNDEFINED  for 
u>h  i  I  e .  .  I  oops  and  f  or  .  .  I  oops  or  INFINITE  for  basic  I  oops,  and  could  trigger  an 
analysis  error  during  the  model  reduction  stage  (Chapter  7).  The  second  method  is  to 
search  for  stated  limits  within  the  program  statement,  and  this  method  is  used  exclusively 
with  for.  .  loops.  A  procedure  called  f  or_  I  oop_f  ound  identifies  the  range 
statement  used  in  the  loop  initialization  and  sends  it  to  a  function  called  evaluate  to 
determine  the  number  of  iterations,  evaluate  uses  various  tools  to  interpret  the 
iteration  range  and  transform  it  to  a  decimal  format.  If  it  is  unsuccessful,  the  loop  entry 
for  the  model  is  given  a  value  element  of  UNDEFINED.  Regardless  of  the  loop  type  or 
its  iteration  limitations,  the  beginning  of  a  loop  construct  also  requires  that  an  ”e  n  d 
I  oop”  entry  is  added  to  end.  I  i  st  to  maintain  an  accurate  picture  of  the  code  nesting. 

IF:  When  an  i  f  statement  is  found,  an  appropriate  entry  is  added  to  the  model, 
provided  that  the  mode  l_act  i  ve  flag  indicates  a  “yes”  value.  Recall  that  the  nature  of 
'.he  test  utilized  by  the  i  f  statement  is  irrelevant  in  this  analysis  and  does  not  affect  the 
development  of  the  source  code  model.  Also,  the  presence  of  an  if  construct  requires 
that  an  “end  i  f ”  entry  is  added  to  end_  I  i  st  to  help  track  the  source  code  nesting. 

ELSE,  ELSIF:  The  e  I  se  and  e  I  s  i  f  statements  are  handled  in  a  manner  similar 
to  the  i  f  statement.  If  the  model  is  currently  active,  an  appropriate  entry  is  made  and  no 
further  action  is  necessary. 

QUEUE,  RETRIEVE,  SEND,  RECEIVE:  Whenever  a  valid  message  passing 
procedure  call  is  found,  an  entry  is  added  to  the  model,  given  that  the  model  is  active.  An 
important  part  of  this  type  of  entry  is  identifying  the  correct  size  of  the  message  being 
passed,  and  there  are  three  possible  sources  for  such  information.  The  first  source  is  the 
comment  information  provided  by  the  programmer.  If  no  comment  information  is 
available,  the  search  procedure  attempts  to  find  the  size  of  the  message  within  the 
parameter  list  of  the  procedure  call.  A  function  called  f  i  nd.paramet  er  extracts  the 
size  parameter  from  the  program  statement  and  uses  the  eva  I  uat  e  tool  to  transform  the 
size  parameter  into  an  integer  value  that  is  returned  to  search.  If  either 
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f  i  nd_ paramet  er  or  evaluate  is  unsuccessful  in  determining  the  message  size,  a 
default  value  is  used  for  the  value  element  of  the  model  entry.  This  default  value  is  taken 
from  the  task  specification  file  during  preliminary  processing  and  is  stored  in  a  data 
structure  called  messages.  A  pointer  to  messages  is  passed  to  search  in  the  event 
that  these  default  values  are  needed  during  model  development. 

END:  As  discussed  previously,  an  end  statement  in  Ada  is  critical  to 
understanding  the  structure  of  the  source  code.  When  an  end  statement  is  found,  a 
procedure  called  end_ found  attempts  to  match  it  to  the  last  entry  in  end- 1  i  s t .  The 
end- 1  i  st  entry  indicates  the  type  of  construct  to  which  the  end  statement  belongs,  and 
each  case  merits  a  unique  response.  Listed  below  are  the  actions  taken  upon  finding  the 
end  statement  for  each  type  of  framed  construct: 

1.  SUBPROGRAM:  First  the  mode  l_act  i  ue  flag  is  deactivated  since  the  end 
statement  indicates  that  the  executable  code  for  that  program  unit  is  complete. 
Next  the  current  code  model  stored  in  skeleton  is  passed  to 
reduce— mode  I  (see  Chapter  1)  in  order  to  refine  the  model  and  remove 
unnecessary  entries.  Finally,  the  subprogram  name  and  model  are  added  to 
the  structure  called  procedures  for  use  in  constructing  subsequent  code 
models. 

2.  PACKAGE:  Finding  the  end  of  a  package  is  critical  to  following  the  naming 
rules  for  subprogram  calls.  If  a  procedure  is  defined  within  a  package,  any 
calls  to  that  procedure  within  the  package  simply  use  the  procedure  name. 
Calls  to  that  subprogram  from  outside  the  package  must  use  the  package  name 
as  a  prefix  so  that  the  call  looks  like  “package_name.subprogram_name.”  In 
order  for  the  code  modeling  process  to  recognize  subprogram  calls  and 
associate  them  with  the  proper  body  of  executable  code,  it  stores  subprogram 
names  so  that  they  always  match  the  names  that  will  be  encountered  in  the 
current  segment  of  source  code.  Thus,  when  the  end  of  a  package  is 
encountered,  the  names  of  subprogram  defined  within  that  package  are  altered 
to  include  the  package  name. 

3.  TASK:  When  the  end  of  a  task  is  found,  the  model  is  deactivated,  and  the 
f  i  n  i  shed  flag  is  set  to  a  “yes”  value  in  order  to  cease  the  model  building 
process. 

4.  LOOP:  If  an  “end  I  oop”  statement  is  found,  an  END_LOOP  entry  is  added 
to  the  model,  provided  that  the  model  is  active. 

5.  IF:  If  an  “end  i  f”  statement  is  found,  an  ENDJF  entry  is  added  to  the 
model,  provided  that  the  model  is  active. 
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6.  CASE:  If  an  “end  case”  statement  is  found,  an  END_CASE  entry  is  added 

to  the  model,  provided  that  the  model  is  active. 

7.  SELECT,  RECORD:  No  specific  action  is  taken. 

In  all  cases,  once  the  tail  entry  in  end_l  i  st  is  matched  and  the  appropriate  action  is 
taken,  that  entry  is  removed  from  e  n  d_  I  i  s  t .  If  a  mismatch  occurs,  the  fatal_error 
flag  is  set  to  “yes”  to  cease  the  current  model  building  process. 

TASK:  When  the  word  “task”  is  encountered,  a  procedure  called 
task-found  extracts  the  name  of  the  task  and  compares  it  with  the  name  of  the  task 
that  is  currently  being  processed.  If  there  is  a  match,  the  task- found  flag  is  set  to 
“yes.”  Also,  an  appropriate  entry  is  added  to  end— I  i  st  regardless  of  whether  a  match 
is  found. 

PACKAGE:  The  bottom-up  model  construction  requires  that  all  packages  listed 
in  the  context  clause  of  an  application  task  are  examined  so  that  any  executable  code  can 
be  modeled.  Thus,  the  source  code  processing  searches  for  packages  on  an  individual 
basis,  and  when  the  word  “package”  is  found,  a  procedure  called  pkg_found 
compares  the  package  name  with  the  name  of  the  package  which  it  expects.  If  there  is  a 
match,  the  pkg_f  ound  flag  is  set  to  “yes,”  and  regardless  of  whether  a  match  is  found, 
an  appropriate  entry  is  added  to  end— I  i  st  to  signify  the  beginning  of  a  package  unit. 

PROC:  When  the  beginning  of  a  subprogram  body  is  found,  a  procedure  called 
pro c_ found  extracts  the  name  of  the  subprogram  and  stores  it  in  procedures  along 
with  the  current  filename,  pro c_ found  also  adds  an  appropriate  entry  to  end_  I  i  st  to 
track  the  source  code  nesting. 

BEGIN:  A  beg  i  n  statement  is  used  by  tasks  and  subprograms  to  indicate  where 
the  executable  code  starts,  and  the  source  code  processing  uses  begin  statements  to 
activate  the  current  model.  If  the  beg  i  n  statement  belongs  to  the  current  task  or  any 
relevant  subprogram,  the  mode  l_act  i  ue  flag  is  set  to  “ye  3.” 

SELECT,  ACCEPT,  RECORD:  When  an  instance  of  “se  I  ect,  accept,’’  or 
“record”  is  found,  an  appropriate  entry  is  added  to  end- 1  i  st.  These  constructs  do 
not  affect  the  code  model,  but  it  is  necessary  to  recognize  their  presence  in  order  to 
properly  track  the  source  code  nesting.  It  is  important  that  end  statements  for  these 
framed  constructs  are  not  confused  with  the  end  statements  of  other  constructs. 

CASE:  When  a  case  statement  is  found,  an  “end  case”  entry  is  added  to 
end-  list,  and  a  CASE  entry  is  added  to  ske  I  et  on,  provided  that  the  model  is  active. 
The  specific  object  of  the  case  statement  is  irrelevant  to  the  modeling  process  and  has 
no  effect. 
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WHEN:  Each  instance  of  “when”  that  is  included  in  the  case  statement  merits 
its  own  entry  in  the  model,  for  each  one  represents  a  different  execution  path  through  the 
source  code.  The  specific  activity  within  the  when  statement  is  modeled  in  the  same 
manner  as  all  other  executable  code. 

procedures:  The  search  procedure  examines  every  program  statement 
looking  for  subprogram  calls,  and  the  list  of  subprograms  that  have  been  modeled  is 
stored  in  procedures.  If  a  subprogram  call  is  found  and  the  current  model  is  active, 
the  subprogram  model  is  copied  directly  from  procedures  into  the  model  stored  in 
ske  I  el  on.  Some  simple  adjustments  are  made  during  the  transfer  to  ensure  that  the 
values  held  in  the  pointer  element  of  the  model  remain  accurate. 

In  conclusion,  the  search  procedure  is  the  true  workhorse  of  the  source  code 
processing.  When  search  completes  the  model  development  for  an  individual  task,  the 
parsing  loop  terminates,  and  the  current  code  model  stored  in  skeleton  is  returned  to 
task-parse  for  model  analysis. 
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Chapter  7 
Model  Analysis 
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The  second  phase  of  the  software  analysis  involves  code  model  analysis.  The 
preceding  chapter  explains  how  source  code  processing  transforms  Ada  code  into  a 
simplified  model  that  is  stored  as  a  collection  of  integers.  The  model  analysis  uses  these 
task  models  produced  by  the  source  code  processing  to  perform  an  efficient,  automated, 
worst  case  analysis  of  the  AFTA  application  task  suite.  All  model  analysis  takes  place 
independent  of  the  original  source  code,  and  the  final  results  are  passed  on  to  the 
hardware  analysis  stage. 

In  the  analysis  of  each  application  task,  the  model  analysis  tools  are  called  upon  to 
perform  two  different  functions.  The  first  function  is  to  reduce  subprogram  models  into  a 
more  efficient  form  before  they  are  stored  in  the  procedures  data  structure.  When  the 
end  of  a  subprogram’s  executable  code  is  encountered  during  source  code  processing,  the 
procedure  called  end_ found  is  responsible  for  transferring  the  current  subprogram 
model  held  in  skeleton  to  its  final  storage  place  in  procedures.  Prior  to  the 
transfer,  end-found  sends  the  model  to  a  procedure  called  reduce_mode  I ,  where 
model  development  is  completed  and  unnecessary  model  entries  are  eliminated.  The 
methods  used  by  reduce_mode  I  are  fully  explained  in  Section  7.2.  The  second 
function  of  the  model  analysis  involves  the  final  parameterization  of  an  application  task. 
Once  t  ask-parse  fully  develops  the  task  model,  it  calls  upon  f  i  nd-iuorst-pat  h  to 
identify  and  quantify  the  worst  case  execution  path  for  that  task.  The  results  are  recorded 
in  the  appropriate  output  file  and  stored  for  later  use  by  the  hardware  analysis.  The 
methods  employed  by  f  i  nd_uior3t_path  are  explored  in  Section  7.4. 

Code  model  analysis  consists  of  three  distinct  stages:  model  preparation,  model 
reduction,  and  execution  path  generation.  The  model  preparation  stage  takes  the  crude 
model  produced  by  source  code  processing  and  completes  its  development  by  defining 
the  depth  and  pointer  elements  for  each  model  entry.  The  model  reduction  stage 
eliminates  unnecessary  model  entries  and  produces  summary  entries  to  replace  inefficient 
groups  of  model  entries.  Lastly,  the  execution  path  generation  stage  uses  the  model  in  its 
final  form  to  identify  all  possible  execution  paths  and  compares  the  paths  in  order  to 
single  out  the  worst  case  path.  The  following  text  details  the  methods  and  motivations  for 
each  of  the  three  stages. 
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7.1  Model  Preparation 

During  source  code  processing,  each  entry  is  added  to  the  current  model  with  only 
the  type  and  value  elements  specified.  The  depth,  pointer,  and  flow  elements  are  all  left 
undefined  during  initial  model  construction  and  later  added  during  model  analysis.  The 
model  preparation  stage  uses  the  nest-leuel  and  match— loops  procedures  to  define 
the  depth  and  pointer  elements  for  each  entry  of  a  given  model,  and  the  result  is  a  model 
that  is  sufficiently  complete  for  execution  path  analysis. 

The  nest  —  I  eue  I  procedure  is  responsible  for  defining  the  depth  element  for 
each  model  entry,  and  in  doing  so,  it  provides  a  clear  picture  of  the  nested  structure  of  the 
original  source  code.  The  depth  element  is  actually  just  an  intermediate  value  that  is 
needed  later  to  establish  the  pointer  element  values  required  during  execution  path 
generation.  Essentially,  the  depth  values  produced  by  ne3t_leuel  can  be  eliminated 
from  the  model  after  the  pointer  elements  are  defined,  but  they  remain  part  of  the  model 
for  purposes  of  model  readability  and  simplified  debugging  of  the  timing  analysis 
software. 


Table  7-1, b 

lesting  Rules  for  nest-leuel 

Entry  Type 

DEPTH  = 

nest  is... 

LOOP 

nest 

incremented 

FORLOOP 

nest 

incremented 

WHILE_LOOP 

nest 

incremented 

IF 

nest 

incremented 

ELS  IF 

nest  -  1 

incremented 

ELSE 

nest  - 1 

incremented 

CASE 

nest 

incremented 

WHEN 

nest  -  1 

incremented 

END_LOOP 

ne3t  -  1 

decremented 

END_IF 

nest  -  1 

decremented 

END_CASE 

nest  -  1 

decremented 

other 

nest 

no  action  taken 

The  nest-leuel  algorithm  uses  an  elementary  loop  to  examine  individual 
model  entries  in  consecutive  order.  An  integer  called  nest  is  established  at  an  initial 
value  of  zero,  and  the  model  is  examined  one  entry  at  a  time  from  beginning  to  end. 
Certain  model  entries  signal  a  deeper  level  of  nesting  in  the  source  code  while  other 
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model  entries  signal  the  opposite.  For  each  type  of  entry,  neat-leoel  defines  the 
depth  element  according  to  the  present  value  of  nest  and  follows  a  predefined  rule  to 
determine  how  that  entry  affects  the  present  nesting  level.  For  instance,  a  LOOP  entry 
signals  an  increase  in  the  nesting  level,  and  an  END_LOOP  entry  signals  a  decrease  in 
the  nesting  level.  Table  7-1  summarizes  the  rules  used  in  the  algorithm;  the  second 
column  shows  what  value  is  used  to  define  the  depth  element,  and  the  third  column  shows 
how  the  nest  value  changes  for  each  entry  type.  Note  that  for  any  complete  body  of 
executable  code  such  as  a  subprogram  body  or  a  task  body,  the  nesting  level  always 
begins  and  ends  at  zero.  If  this  is  not  the  case,  it  signifies  that  a  fatal  error  has  occurred 
during  the  source  code  processing,  and  it  is  properly  noted  in  the  error  file. 

The  match— I  oops  procedure  is  responsible  for  linking  related  model  entries 
through  appropriate  definitions  of  their  pointer  elements.  When  the  model  analysis 
attempts  to  identify  possible  execution  paths  through  the  original  source  code,  the 
analysis  must  be  able  to  recognize  connections  between  related  model  entries  in  order  to 
trace  a  functionally  correct  path.  Thus  the  pointer  element  becomes  a  key  factor  during 
the  path  generation  stage.  The  following  example  should  clarify  this  concept. 


1 

i  f  A  =  B  then 

2 

compute  (X  ■>  10); 

3 

e  1  s  i  f  B  =  C  then 

4 

compute  (X  =>  20); 

5 

else  compute  (X  =>  30); 

6 

end  i f ; 

Figure  7-1,  A  Sample  i  f  Construct 


Figure  7-1  is  a  simple  Ada  i  f  construct  that  illustrates  the  use  of  the  pointer 
element  in  a  source  code  model.  There  are  three  possible  execution  paths  through  this 
construct.  If  the  conditional  test  in  line  1  is  true,  execution  proceeds  from  line  1  to  line  2 
to  line  6.  If  the  condition  in  line  1  is  false  and  the  condition  in  line  3  is  true,  the  execution 
path  includes  lines  1,3,4,  and  6.  Lastly,  if  both  conditionals  are  false,  the  execution  path 
includes  lines  1,3,5,  and  6.  Following  the  logic  of  the  construct  shown  above  seems  to  be 
a  trivial  task,  but  for  an  automated  analysis,  the  logic  must  be  built  into  the  code  model  in 
a  format  that  is  understood  by  the  path  generation  tools.  When  generating  an  execution 
path,  the  analysis  must  know  that  if  the  first  conditional  is  assumed  false,  the  execution 
path  skips  line  2  and  proceeds  to  line  3.  Likewise,  if  the  second  conditional  is  assumed  to 
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be  false,  the  execution  path  skips  line  4  and  proceeds  to  line  5.  For  this  reason,  the 
pointer  elements  for  conditional  entries  in  the  model  are  needed  to  direct  the  execution 
path  generator  to  the  next  valid  section  of  code  in  the  event  that  a  particular  section  of 
code  is  bypassed  due  to  the  outcome  of  a  conditional  statement.  The  exact  methods  of 
path  generation  are  explained  in  Section  7.3;  at  this  point,  it  is  only  important  to 
understand  the  motivation  for  the  pointer  element. 

The  match- 1  oops  procedure  examines  a  given  model  after  the  depth  elements 
are  specified,  and  it  proceeds  to  link  related  entries  and  install  execution  path  logic 
through  the  pointer  elements.  Only  certain  types  of  model  entries  must  have  their  pointer 
fields  defined,  and  in  such  cases,  the  following  rules  apply: 

1.  A  LOOP  entry  points  to  its  corresponding  END_LOOP  entry. 

2.  A  FOR_LOOP  entry  points  to  its  corresponding  END_LOOP  entry. 

3.  A  WHDLE_LOOP  entry  points  to  its  corresponding  END_LOOP  entry. 

4.  An  ENDJLOOP  entry  points  to  the  entry  representing  the  beginning  of  the 
loop. 

5.  A  CASE  entry  points  to  the  first  corresponding  WHEN  entry  that  follows. 

6.  A  WHEN  entry  points  to  the  next  corresponding  WHEN  or  END_CASE 
entry. 

7.  An  END_CASE  entry  points  to  the  corresponding  CASE  entry. 

8.  An  IF  entry  points  to  the  next  corresponding  ELSIF,  ELSE,  or  END_IF  entry. 

9.  An  ELSIF  entry  points  to  the  next  corresponding  ELSIF,  ELSE,  or  ENDJF 
entry. 

10.  An  ELSE  entry  points  to  its  corresponding  ENDJF  entry. 

11.  An  ENDJF  entry  points  to  its  corresponding  IF  entry. 

Notice  in  the  rules  listed  above  that  the  key  to  proper  pointer  definition  involves  finding 
the  corresponding  entry  of  a  particular  type.  This  is  where  the  depth  element  becomes 
necessary.  Consider  the  following  nested  i  f  construct: 


1 

i  f  A  =  B  then 

2 

i  f  B  =  C  then 

3 

compute(X  =>  10); 

4 

end  i f ; 

5 

else  compute(X  =>  20); 

6 

end  if; 

Figure  7-2,  A  Sample  Nested  i  f  Construct 
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When  setting  up  pointer  elements  for  the  construct  shown  in  Figure  7-2,  there  is  some 
confusion  if  the  depth  element  is  not  utilized.  The  pointer  definition  rules  state  that  the  IF 
entry  taken  from  line  1  should  point  to  its  corresponding  END_IF  entry,  which  is  taken 
from  line  6  in  this  example.  If  the  mat  ch_  I  oops  procedure  defines  the  pointer  element 
in  accordance  with  the  next  END_IF  entry,  it  commits  an  error  by  designating  the 
END_IF  entry  taken  from  line  4  of  the  preceding  figure.  The  depth  element  is  the  key  to 
distinguishing  between  the  “end  if”  statements  in  lines  4  and  6.  Notice  that  for  both 
the  outer  i  f  construct  and  the  nested  i  f  construct,  the  related  “i  f”  and  “end  i  f” 
statements  have  identical  depth  values  defined  within  the  model.  Thus,  for  an  IF  entry, 
match- 1  oops  is  able  to  find  the  corresponding  END_IF  entry  by  searching  for  the  next 
END_IF  entry  that  has  a  depth  value  identical  to  that  of  the  IF  entry.  Essentially,  the 
depth  element  allows  the  automated  model  analysis  tools  to  understand  the  concept  of 
corresponding  model  entries. 

7.2  Model  Reduction 

After  a  given  model  is  processed  by  nest-  I  eue  I  and  mat  ch_  I  oops,  that 
model  is  complete,  but  it  is  not  necessarily  an  efficient  representation  of  the  original 
source  code.  There  are  situations  where  model  entries  can  be  eliminated  without  altering 
the  analysis  results,  and  there  are  other  situations  where  a  group  of  model  entries  can  be 
summarized  effectively  by  a  single  model  entry  in  order  to  reduce  the  size  and 
complexity  of  the  model. 

The  process  of  entry  elimination  is  reserved  for  situations  involving  empty  loops. 
An  empty  loop  is  defined  as  a  LOOP  entry  followed  directly  by  an  END_LOOP  entry.  It 
is  reasonable  to  assume  that  the  original  source  code  does  not  contain  such  empty  loops, 
but  it  is  incorrect  to  make  the  same  assumption  about  the  source  code  model.  The 
concept  of  abstraction  allows  the  code  model  to  omit  details  that  are  considered 
irrelevant  to  the  timing  analysis,  and  it  is  possible  that  the  source  code  processing  could 
add  a  loop  structure  to  the  model  and  simultaneously  find  nothing  within  that  loop  that  is 
important  enough  to  record  in  the  model.  The  result  is  an  empty  loop  that  adds 
unnecessary  complexity  to  the  task  of  generating  execution  paths  for  the  complete  model, 
and  the  proper  course  of  action  is  simply  to  delete  the  loop  from  the  model.  However, 
there  is  a  restriction  on  the  types  of  empty  loops  that  can  be  eliminated  without  altering 
the  analysis  results.  The  primary  constraint  is  that  the  loop’s  iteration  limit  must  be 
defined  before  the  loop  can  be  deleted.  In  other  words,  if  the  value  element  for  the  LOOP 
entry  is  listed  as  UNDEFINED  or  INFINITE,  the  loop  must  remain  in  the  model  to 


ensure  that  the  undefined  behavior  of  the  construct  is  properly  noted  in  the  error  file 
during  future  analysis.  As  long  as  the  loop’s  value  element  is  defined,  any  empty 
f or .  .  I  oop,  uih i  I  e  .  .  I  oop, or  basic  loop  is  removed  during  model  reduction.  This 
elimination  process  may  seem  to  be  a  reckless  omission  of  detail  by  the  model  analysis, 
but  the  responsibility  for  model  accuracy  actually  lies  with  the  source  code  processing.  If 
the  source  code  processing  recognizes  a  program  statement  as  significant  to  the  timing 
analysis,  it  is  recorded  in  the  model  and  accounted  for  in  the  model  analysis.  If  a  program 
statement  is  ignored  in  the  model  development  and  an  empty  loop  results,  the  model 
analysis  is  held  accountable  for  it. 

When  the  model  analysis  attempts  to  generate  execution  paths,  the  processing 
workload  is  significantly  decreased  by  reducing  the  model  to  a  more  efficient  format. 
Consider  the  following  loop  and  its  model: 


I  oop 

for  i  i n  1 . . 3  I oop 

rg_commun i cat  ion. queue_me33age(-, -,-,50,-,-); 


w  1  1  VJ  1  f 

schedu  1  er  .  uta  i  t_ 

for_3chedu 1 e; 

end  1 

oop; 

INDEX 

TYPE 

UftLUE 

DEPTH 

POINTER 

0 

LOOP 

INFINITE 

0 

5 

1 

F0R_L00P 

3 

1 

3 

2 

QUEUE 

50 

2 

UNDEF ! 

INED 

3 

END_L00P 

UNDEFINED 

1 

1 

4 

UFS 

UNDEFINED 

1 

UNDEF 1 

INED 

5 

END-LOOP 

UNDEFINED 

0 

0 

Figure  7-3,  A  Sample  Nested  Loop  and  its  Model 


When  the  model  analysis  generates  an  execution  path  for  the  model  shown  in  Figure  7-3, 
it  produces  the  following  sequence:  0,1, 2, 3, 1,2,3, 1,2,3, 4.  Notice  the  repetition  of  the 
inner  loop,  and  imagine  what  the  sequence  would  look  like  if  the  loop  bound  was  1(X) 
iterations  rather  than  three  iterations.  In  situations  such  as  this,  the  path  generation 
process  is  inefficient  and  at  times  unmanageable.  It  is  therefore  advantageous  to 
summarize  the  inner  loop  with  a  single  model  entry  called  a  COUNTER_SET  entry.  The 
COUNTER_SET  entry  parameterizes  the  execution  information  held  in  a  contiguous 
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group  of  model  entries  and  is  then  used  to  replace  that  group  of  entries.  The 
COUNTER_SET  entry  is  merely  a  collection  of  integers  that  indicate  how  many  times 
each  critical  construct  is  encountered  during  execution  of  a  given  segment  of  code;  its 
format  is  shown  below: 


counter_3et 

(structure) 

num-sent 

( integer) 

num_read 

( integer) 

num_queued 

( integer) 

num_retr i eued 

( i nt  eger ) 

rg_log_entr i es 

( integer) 

debug_entr i es 

( i nteger ) 

i o_ut i 1 3 

( integer) 

Figure  7-4,  Format  for  a  COUNTER_SET  Entry 


Notice  that  the  COUNTER_SET  structure  includes  a  counter  for  every  critical  construct 
that  does  not  pertain  to  the  control  of  execution  flow.  In  other  words,  it  accounts  for 
events  like  operating  system  calls  while  ignoring  the  elements  of  loop  constructs  and 
conditional  statements.  This  structure  is  also  used  to  store  the  final  parameterized 
representation  of  the  application  task  that  is  ultimately  produced  by  the  model  analysis. 
In  this  particular  example,  the  COUNTER_SET  entry  records  a  value  of  150  bytes  for  the 
num-queued  counter  because  a  50  byte  message  is  queued  for  each  of  the  three  inner 
loop  iterations.  All  other  counters  remain  at  their  initial  values  of  zero.  In  this  manner, 
COUNTER_SET  records  all  the  necessary  execution  information  held  by  entries  1 ,2,  and 
3  in  the  model  of  Figure  7-3,  and  it  greatly  simplifies  the  process  of  execution  path 
generation.  Refer  to  Figure  7-5  for  an  updated  version  of  the  model  shown  in  Figure  7-3. 


INDEX 

TVPE 

URLUE 

DEPTH 

POINTER 

0 

LOOP 

INFINITE 

0 

3 

1 

COUNTER-SET 

0 

1 

UNDEFINED 

2 

UFS 

UNDEFINED 

1 

UNDEFINED 

3 

END-LOOP 

UNDEFINED 

0 

0 

Figure  7-5,  An  Updated  Model 
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Notice  that  the  inner  loop  disappears,  and  the  pointer  value  for  the  top  entry  is  adjusted 
accordingly.  The  COUNTER_SET  entry  is  given  a  value  of  0  since  it  is  the  first  entry  of 
its  type  in  the  model,  and  it  assumes  a  depth  value  equal  to  the  depths  of  the  first  and  last 
entries  in  the  set  of  entries  that  is  replaced.  Part  of  the  data  structure  used  to  store  code 
models  is  reserved  for  an  array  of  COUNTER_SET  records  having  the  format  shown  in 
Figure  7-4.  The  value  element  of  the  COUNTER_SET  entry  corresponds  to  the 
COUNTER_SET  array  index  used  to  access  the  counters.  The  proper  execution  path 
sequence  for  the  updated  model  is  now  shortened  to  the  following:  0,1,  and  2.  The 
method  by  which  a  COUNTER_SET  entry  is  accounted  for  in  the  quantification  and 
evaluation  of  execution  paths  is  explored  in  Section  7.3. 

The  process  of  summarizing  groups  of  model  entries  may  seem  to  be  modeling 
overkill,  but  it  is  necessary  to  make  the  task  of  execution  path  generation  a  manageable 
one.  It  also  may  seem  that  the  application  of  this  process  is  not  properly  bounded  because 
it  theoretically  could  be  applied  to  any  coherent  set  of  entries,  but  this  is  not  so.  This  type 
of  model  reduction  is  strictly  limited  to  the  following  classes  of  constructs: 

1.  A  for ..  I  oop  with  a  defined  iteration  limit  and  no  WFS  entry  within  the 
loop. 

2.  A  uih  i  I  e  .  .  I  oop  with  a  defined  iteration  limit  and  no  WFS  entry  within  the 
loop. 

3.  A  basic  loop  with  a  defined  iteration  limit  and  no  WFS  entry  within  the  loop. 

4.  An  i  f  construct  containing  no  WFS  entry. 

5.  A  case  construct  containing  no  WFS  entry. 

The  reason  why  these  constructs  must  not  encapsulate  a  call  to  uia  i  t_f  or_schedu  I  e 
is  that  the  WFS  call  is  critical  to  the  process  of  execution  path  generation.  Recall  that  a 
single  execution  cycle  consists  of  all  program  statements  executed  between  two 
consecutive  WFS  calls.  As  such,  all  WFS  calls  must  remain  in  the  model  for  any 
subprogram  or  application  task  so  that  they  can  be  referenced  as  beginning  and  end  points 
for  various  execution  paths.  Concealing  a  WFS  call  inside  the  summary  of  a 
COUNTER_SET  entry  destroys  the  functionality  of  WFS  entries  within  the  realm  of 
model  analysis. 

The  transformation  from  a  qualified  group  of  entries  to  a  single  COUNTER_SET 
entry  takes  place  in  a  procedure  called  crunch.  This  procedure  is  called  five  separate 
times  by  its  parent  procedure,  reduce_mode  I ,  and  each  call  corresponds  to  one  of  the 
five  types  of  constructs  that  are  listed  above.  Once  invoked,  crunch  first  searches  for 
qualified  groups  of  entries  belonging  to  a  particular  type  of  construct;  for  instance,  it  may 
search  for  all  urh  i  I  e  .  .  I  oops  that  contain  no  WFS  entries.  For  each  group  that  is 
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found,  crunch  creates  a  temporary  model  containing  only  the  entries  from  that  group, 
and  it  sends  the  temporary  model  to  a  procedure  called  genera t  e_pat  hs  for  a  ‘‘mode 
1”  path  analysis.  The  function  of  generate-palha  is  to  identify  all  execution  paths 
through  a  given  model,  parameterize  them,  compare  them,  and  single  out  the  worst  path. 
A  “mode  2”  path  analysis  refers  to  the  process  of  identifying  and  comparing  execution 
paths  that  proceed  from  one  WFS  call  to  the  next  WFS  call.  This  is  the  type  of  analysis 
that  is  performed  on  the  complete  application  task  model  in  search  of  the  worst  case 
parameterization  of  that  task.  A  “mode  1”  analysis  involves  finding  all  execution  paths 
that  strictly  proceed  from  the  first  model  entry  to  the  last  model  entry.  Since  crunch 
deals  only  with  groups  of  model  entries  containing  no  WFS  calls,  a  “mode  1”  analysis  is 
the  correct  and  logical  choice.  It  may  seem  too  complex  to  give  the  same  procedure  the 
responsibility  for  performing  two  different  types  of  analyses,  but  the  implementations  of 
“mode  1”  and  “mode  2”  path  analyses  are  so  similar  that  using  two  versions  of 
generat  e_pat hs  would  create  unnecessary  redundancy.  The  results  produced  by 
generate_paths  are  sent  back  to  crunch  in  the  form  of  a  COUNTER_SET  entry, 
and  crunch  performs  the  COUNTER„SET  substitution  within  the  original  subprogram 
model  or  task  model. 

The  example  shown  in  Figure  7-3  illustrates  how  the  length  of  execution  path 
sequences  is  significantly  reduced  through  model  reduction.  It  is  also  important  to 
understand  how  model  reduction  further  decreases  the  analysis  workload  by  eliminating 
possible  execution  paths  from  consideration  during  the  final  task  analysis.  Suppose  a  task 
model  contains  a  basic  i  f  construct  that  includes  both  an  e  I  s  i  f  and  an  e  I  se  statement. 
Such  a  construct  has  two  conditional  statements  and  three  possible  paths  of  execution. 
The  crunch  procedure  finds  the  construct,  develops  an  independent  model  from  it,  and 
submits  it  to  general  e_paths  for  a  “mode  1”  analysis.  The  path  analysis  generates 
the  three  possible  paths  through  the  construct,  parameterizes  them,  compares  them,  and 
singles  out  the  worst  of  the  three.  It  returns  its  results  to  crunch  in  the  form  of 
parameter  set,  and  crunch  replaces  the  original  i  f  construct  with  a  COUNTER_SET 
entry  and  reduces  the  size  and  complexity  of  the  task  model.  The  actual  model  reduction 
is  a  positive  result  from  this  process,  but  it  is  not  the  most  significant  result  in  this 
particular  case.  It  i°  more  important  to  recognize  the  fact  that  an  i  f  construct  that  allows 
three  distinct  paths  is  replaced  by  a  COUNTER_SET  entry  that  allows  only  one  path. 
Thus  the  total  number  of  possible  execution  paths  through  the  task  model  is  decreased  by 
a  factor  of  three.  By  isolating  the  i  f  construct  to  identify  its  own  worst  case  path,  the 
workload  required  to  process  the  full  task  model  is  tremendously  reduced.  In  a  similar 
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manner,  replacing  a  case  construct  with  four  options  cuts  the  number  of  execution  paths 
through  a  task  by  a  factor  of  four. 

7.3  Execution  Path  Generation 

Recall  that  the  purpose  of  source  code  modeling  is  to  provide  an  effective  and 
efficient  means  to  identify  the  worst  case  execution  path  through  a  given  application  task. 
The  processes  of  model  development,  preparation,  and  reduction  lay  the  foundation  for 
the  most  crucial  stage  of  the  analysis:  execution  path  generation.  The  path  analysis 
process  has  the  following  three  objectives: 

1.  To  identify  all  possible  execution  paths  through  a  given  model. 

2.  To  accurately  parameterize  each  path  generated. 

3.  To  evaluate  the  parameterizations  and  identify  a  single  worst  case  path. 

In  order  to  understand  the  methods  employed  by  the  path  analysis,  it  is  best  to  first 
explore  the  general  nature  of  the  task  at  hand. 


if  fl 

=  B  then  compute  (X  =  > 

10;; 

e  1 

s i f  fl  =  C  t  hen 

i f  B  =  D  then  compute 

(X  => 

20) 

elaif  B  =  10  then  compute 

(X  =>  25) 

else  compute  (X  => 

30) 

end  i  f ; 

e  1 

s i f  fl  =  D  then  compute 

(X  => 

35); 

e  1 

se  fl  =  10; 

end 

•  f ; 

Figure  7-6,  A  Nested  i  f  Construct 


Consider  the  nested  i  f  construct  shown  in  Figure  7-6.  There  are  six  possible 
paths  through  this  construct,  and  each  path  must  be  explored  and  compared  against  the 
others  with  respect  to  execution  delay.  A  decision  tree  developed  from  this  construct  is 
shown  in  Figure  7-7;  notice  that  the  circled  items  represent  the  leaves  of  the  tree,  which 
are  actually  the  endpoints  of  the  six  execution  paths.  Each  conditional  statement  in  the 
construct  is  shown  as  a  decision  point  in  the  tree,  and  each  decision  has  two  possible 
results,  as  represented  by  the  left  and  right  branches.  The  various  locations  on  the  tree  are 
uniquely  expressed  in  a  binary  format  based  upon  which  branch  is  taken  at  each  decision 
point  encountered  along  the  path  to  that  location.  A  left  branch  is  represented  by  a  '  1.' 
and  a  right  branch  is  represented  by  a  ‘0.’  The  digits  are  listed  in  the  order  in  which  the 
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decisions  are  made.  The  critical  result  of  all  these  conventions  is  that  the  location  of  each 
leaf  or  endpoint  is  expressed  as  a  binary  number  that  directly  correlates  to  the  execution 
path  taken  to  reach  that  endpoint. 


Figure  7-7,  A  Nested  i  f  Decision  Tree 


A  manual  path  analysis  would  probably  utilize  a  decision  tree  similar  to  that 
shown  in  Figure  7-7,  for  once  the  tree  is  developed,  it  is  a  trivial  task  to  map  out  all  the 
possible  execution  paths.  The  challenge  of  the  automated  model  analysis  is  to  develop  an 
algorithm  that  uses  analogous  methods  to  produce  the  same  results  as  the  manual 
analysis.  The  resulting  algorithm  must  achieve  the  following  three  goals: 

1.  The  algorithm  must  be  able  to  comprehend  the  functionally  of  the  code  model 
and  generate  execution  paths  using  the  tree-like  format  shown  in  the  figure 
above. 

2.  It  must  be  able  to  fully  explore  the  paths  through  the  tree  and  know  when  all 
paths  have  been  explored. 

3.  The  algorithm  must  be  efficient  enough  to  avoid  tracing  the  same  execution 
path  more  than  once. 

The  predefined  format  of  the  code  model  and  the  ability  to  define  a  path  through  the  tree 
as  a  binary  number  are  key  facilitating  factors  in  the  development  of  the  path  generation 
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algorithm.  The  following  explanation  and  walk-through  example  highlights  the  methods 
used  to  achieve  the  goals  listed  above. 

The  path  generation  algorithm  primarily  focuses  upon  the  process  of  generating 
the  binary  values  that  correspond  to  the  individual  paths  and  their  respective  endpoints. 
Two  integer  variables  control  all  activity  involved;  one  is  called  shi  ft -number  and  the 
other  is  known  as  the  decision  integer,  shi  ft -number  tracks  the  length  of  the 
current  execution  path,  and  the  value  of  the  decision  integer  predetermines  the 
decisions  made  at  each  decision  point  along  the  current  path.  It  is  best  to  think  of  the 
dec  i  s  i  on  integer  in  terms  of  its  binary  representation,  for  the  ‘l’s  and  ‘0’s  are  what 
actually  determine  the  decisions  made,  dec  i  s  i  on  is  initialized  to  a  value  of  zero,  which 
determines  the  first  path  that  is  explored,  and  after  each  path  is  completed,  the  value  of 
decision  is  updated  in  such  a  manner  that  it  predetermines  the  next  path  to  be 
examined.  The  updating  process  is  designed  specifically  to  ensure  that  all  paths  are 
explored  once  and  only  once  and  to  notify  the  algorithm  when  the  exploration  is 
complete.  For  an  illustrative  example,  the  path  generation  algorithm  is  applied  to  the  tree 
in  Figure  7-7,  and  the  values  of  shi  ft -number  and  decision  at  each  step  of  the 
algorithm  are  laid  out  in  Table  7-2. 

The  decision  integer  is  shown  in  an  eight  bit  binary  format  with  the  most 
significant  bit  separated  from  the  others.  The  MSB  is  called  the  “done  bit”  because  when 
it  changes  from  a  ‘0’  to  a  ‘1,’  it  signals  the  algorithm  that  the  path  generation  process  is 
complete.  The  presence  of  the  “done  bit”  leaves  only  7  bits  of  the  dec  i  s  i  on  integer  for 
use  in  the  path  generation  process,  and  this  is  signified  in  the  initial  value  of 
sh  i  ft_ number.  The  algorithm  begins  with  dec  i  s  i  on  initialized  to  zero,  and  it  starts 
at  the  top  of  the  tree  with  the  first  decision  point.  The  outcome  of  the  first  decision  is 
determined  by  the  value  of  the  bit  adjacent  to  the  “done  bit,”  and  accordingly  the  right 
branch  is  chosen.  Once  a  decision  bit  is  referenced,  it  is  not  used  again  until  the  next  path 
is  explored.  Subsequent  decisions  are  made  by  referencing  the  next  least  significant  bit 
within  the  decision  integer.  For  every  decision  bit  used,  shi  ft_n  umber  is  decremented 
once  to  track  the  number  of  available  decision  bits  remaining.  For  the  first  execution  path, 
all  decision  bits  are  ‘0’s,  and  the  right  branch  is  taken  at  three  success  ve  decision  points 
until  the  endpoint  labeled  “000”  is  reached.  As  expected,  the  binary  value  of  the  endpoint 
is  identical  to  the  series  of  decision  bits  referenced  in  arriving  at  that  location.  The 
second  line  of  the  table  shows  the  three  decision  bits  used,  and  it  lists  shi  ft -number 
with  a  value  of  4  since  there  are  four  decision  bits  unused  for  the  first  path.  At  this  point, 
the  decision  integer  is  updated  to  prepare  for  the  next  path.  The  update  consists  of  adding 
a  ‘  1’  to  the  last  decision  bit  used,  and  this  is  accomplished  by  taking  an  integer  value  of  1 


I 

and  shifting  its  bits  left  by  4  places.  Notice  the  correspondence  to  the  current  value  of 
ah i ft_number. 

I 


Table  7-2,  A  Path  Generation  Example 


Path 

Decision  Integer 

Comment 

1 

0  0000000 

7 

Initial  value  of  decision 

1 

4 

First  three  decision  bits  are  used 

2 

0  0010000 

7 

A  1  has  been  added  to  last  bit  used 

2 

4 

First  three  decision  bits  are  used 

3 

0  0100000 

7 

A  1  has  been  added  to  last  bit  used 

3 

3 

First  four  decision  bits  are  used 

4 

0  0101000 

7 

Add  1  to  the  last  active  bit 

4 

1 

3 

First  four  decision  bits  are  used 

5 

0  0  1  10000 

7 

Add  1  to  the  last  active  bit 

5 

4 

Only  three  decision  bits  needed 

6 

0  1000000 

7 

Add  1  to  the  last  active  bit 

6 

0  1 

6 

Only  a  single  decision  bit  is  needed 

n 

1  0000000 

7 

The  MSB  changes;  process  is  done 

The  updated  value  of  dec  i  a  i  on  predetermines  the  decisions  that  will  be  made  in 
exploring  the  next  new  path.  It  guarantees  that  the  new  path  will  not  be  a  repetition  of 
any  previously  explored  path  because  the  decision  integer  assumes  a  new  and  unique  I 

value.  The  next  state  of  the  decision  integer  always  depends  upon  the  present  state,  and 
the  use  of  addition  to  transition  between  states  guarantees  that  all  states  are  unique.  The 
only  way  that  a  state  can  be  repeated  is  if  the  integer  becomes  so  large  that  its  value  rolls 
over,  but  before  this  happens,  the  “done  bit”  is  forced  to  transition  from  a  ‘0’  to  a  ‘1.’  I 

Such  a  transition  automatically  triggers  the  end  of  the  algorithm  and  thus  prevents  state 
repetition.  The  basic  idea  behind  the  update  methodology  is  that  changing  the  last 
decision  made  leads  to  at  least  one  new  endpoint,  and  it  possibly  leads  to  a  whole  series 
of  new  endpoints  springing  from  previously  unencountered  decision  points.  If  the  last  I 

decision  that  was  made  corresponds  to  a  left  branch  decision  (a  decision  bit  equal  to  ‘  1’), 
adding  a  ‘1’  to  the  appropriate  bit  invoices  a  “bit  carry”  and  effectively  changes  a  decision 
bit  further  upstream.  It  simultaneously  clears  or  refreshes  all  the  downstream  decision 
bits.  The  refresh  activity  ensures  a  complete  exploration  of  any  new  branch  in  the  same  I 

manner  that  the  initial  zero  value  for  dec  i  s  i  on  ensures  complete  exploration  of  the 
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entire  tree.  The  update  process  is  deceptively  simple,  for  a  seemingly  trivial  addition 

process  automatically  deals  with  all  issues  of  path  repetition,  path  exhaustion,  and  ' 

notification  of  completion.  The  third  line  of  the  table  lists  the  updated  decision  integer 

that  is  used  to  generate  the  second  path.  As  with  the  first  path,  the  first  three  decision  bits 

are  used,  and  this  leads  to  a  bit  carry  when  updating  decision  for  the  third  path.  The 

bit  carry  appropriately  changes  the  value  of  the  second  decision  bit  and  refreshes  the 

value  of  any  downstream  decision  bits.  The  algorithm  continues  as  described  until  all  six 

paths  are  explored.  While  updating  the  decision  integer  in  preparation  for  a  seventh  path, 

the  “done  bit”  registers  a  ‘1,’  and  the  algorithm  automatically  terminates. 

The  algorithm  implemented  in  generat  e_pat  hs  is  quite  similar  to  the  one  » 

described  in  the  preceding  example,  but  it  is  slightly  more  complex  because  it  must 
transform  the  code  model  into  a  decision  tree  format  as  it  executes  the  path  generation 
algorithm.  A  flow  chart  for  generat  e_paths  is  included  on  the  following  page.  As 
described  previously,  this  procedure  performs  two  types  of  path  analyses.  The  algorithm  » 

is  identical  for  both  types;  the  main  differences  between  the  two  are  the  starting  points 
and  the  ending  conditions  for  individual  paths.  The  “mode  2”  analysis  is  for  finding 
paths  through  the  complete  task  model.  Each  path  begins  at  the  entry  following  a  WFS 
entry  and  ends  with  a  WFS  entry.  The  “mode  1”  analysis  is  used  during  model  reduction,  » 

and  every  path  begins  at  the  first  model  entry  and  ends  with  the  last  model  entry.  As  the 
procedure  proceeds  through  the  path  generation,  the  index  values  for  entries  encountered 
along  the  path  are  stored  in  a  one-dimensional  integer  array  called  path.  When  called, 
generat  e_paths  is  given  the  index  value  for  the  first  entry  on  the  path.  It  evaluates  t 

that  entry  to  determine  if  it  is  a  decision  point,  and  if  it  is,  a  procedure  called  decide  is 
used  to  manipulate  the  dec  i  3  i  on  integer  to  find  the  next  step  along  the  path.  Note  that 
the  dec  i  3  i  on  integer  is  expanded  to  a  64  bit  number  in  this  implementation  of  the 
algorithm  to  account  for  the  complexity  of  complete  task  models.  Only  a  few  types  of  > 

model  entries  prompt  a  decision  process;  these  are  listed  below: 

1.  IF 

2.  ELSIF 

3.  ELSE  , 

4.  WHEN 

5.  WHILEJLOOP 

6.  END_LOOP 

Depending  upon  the  outcome  of  the  decision,  the  flow  element  is  sometimes  activated  for  » 

certain  entries  that  follow  the  decision  point.  Consider  the  case  of  an  i  f  construct  in 
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Figure  7-8,  The  generate_paths  Algorithm 


which  the  i  f  condition  is  assumed  to  be  true.  This  corresponds  to  taking  the  first  left 
branch  in  the  decision  tree  of  Figure  7-7.  Once  the  left  branch  is  chosen,  all  e  I  3  i  f  and 
else  branches  within  that  i  f  construct  are  excluded  from  the  execution  path.  The  flow 
elements  of  the  ELSIF  and  ELSE  branch  entries  are  set  to  a  value  called  NO_EXEC  in 
order  to  signal  the  algorithm  that  those  entries  are  no  longer  valid  steps  along  the  path. 
When  generate_paths  encounters  a  NO_EXEC  entry  within  its  path,  it  knows  not  to 
add  the  index  value  of  that  entry  to  the  current  path  array,  and  it  proceeds  to  examine 
the  next  consecutive  entry. 

Now  consider  the  situation  where  an  i  f  condition  is  assumed  to  be  false,  and  the 
if.,  then  branch  is  excluded  from  the  path.  The  value  of  the  pointer  element  at  the  IF 
entry  allows  generat  e_pat  hs  to  skip  the  entries  of  the  if  .  .then  branch  and  go 
directly  to  the  next  decision  point  or  to  the  conclusion  of  the  i  f  construct,  whichever 
comes  first.  When  generat  e_paths  encounters  a  model  entry  that  is  not  a  decision 
point  and  does  not  have  its  flow  entry  defined,  it  merely  adds  that  entry  index  to  the  path 
and  continues  on  to  the  next  consecutive  entry. 

When  a  path  trace  is  complete,  generat  e_pat  h3  sends  the  path  array  to  a 
procedure  called  parameterize,  which  quantifies  the  path  in  terms  of  the 
count er_set  structure  described  in  Section  4.6.2.  The  parameterization  essentially 
retraces  the  path  and  examines  the  type  and  value  elements  of  the  appropriate  model 
entries.  When  it  finds  an  entry  which  contributes  to  one  of  the  execution  delay  factors 
specified  in  the  count  er_set  structure,  it  simply  updates  the  value  of  the  related 
counter  according  to  the  value  element  of  the  model  entry.  The  result  of  this  process  is  a 
simple  collection  of  counters  that  quantify  the  timing  behavior  of  a  given  path  through  a 
given  model.  It  may  seem  that  the  count  er_set  structure  is  too  limited  in  scope  to 
properly  characterize  the  timing  behavior  of  an  execution  path,  but  keep  in  mind  that  the 
parameter  list  can  and  will  be  expanded  in  future  efforts  to  improve  the  code  modeling 
process.  The  current  set  of  critical  constructs  that  drive  the  code  model  development  w  ill 
grow  as  the  ATTA  testing  and  system  evaluation  progress. 

Once  the  parameterization  is  complete,  the  parameter  set  is  returned  to 
generat  e_paths,  which  sends  it  to  the  hardware  analysis  tools  where  an  actual  lower 
bound  on  execution  delay  is  estimated  based  upon  the  parameter  values  submitted.  The 
hardware  analysis  methods  are  explored  in  Chapter  8.  Given  a  single  delay  value  for 
each  path,  generat e_pat hs  easily  compares  the  paths  and  identifies  which  path 
causes  the  greatest  execution  delay.  After  all  paths  have  been  traced,  parameterized, 
evaluated,  and  compared,  generat e_paths  returns  to  its  parent  procedure  a  single  set 


of  parameters  that  represent  the  worst  case  path  through  the  given  model  for  the  given 
mode  of  analysis. 

7.4  Managing  Model  Analysis 

The  preceding  sections  focus  upon  the  motivations  and  methodology  of  code 
model  analysis.  It  is  now  useful  to  discuss  the  manner  in  which  these  analysis  activities 
are  managed. 

A  procedure  called  reduce_mode  I  is  a  simple  series  of  procedure  calls  that 
oversees  model  preparation  and  reduction.  It  begins  with  a  call  to  nest- !  sue  I ,  which 
is  followed  by  a  call  to  match_l  oops.  Once  the  model  preparation  is  complete,  the 
model  is  submitted  to  a  procedure  called  mode  l_ok,  where  the  model’s  validity  is 
confirmed  prior  to  any  further  processing,  mode  I  — ok  performs  a  series  of  routine 
checks  to  ensure  that  the  model  is  able  to  undergo  execution  path  analysis  without 
causing  a  run-time  error  for  the  timing  analysis  software.  A  list  of  these  diagnostics  is 
included  below: 

1.  Does  model  depth  begin  and  end  at  zero? 

2.  Are  all  I  oop,  i  f,  and  case  constructs  complete  with  end  statements? 

3.  Are  there  any  true  infinite  loops  with  no  WFS  calls  inside? 

4.  If  the  model  is  a  task  model,  is  there  at  least  one  WFS  entry? 

5.  Are  any  non-existent  COUNTER_SET  entries  included  in  the  model? 

Any  errors  identified  by  mode  1  _ok  are  specifically  noted  in  the  error  file.  Obviously,  no 
errors  are  expected,  but  this  type  of  preventive  check  helps  avoid  a  situation  in  which  a 
single  erroneous  subprogram  model  crashes  the  entire  AFTA  timing  analysis.  After  the 
model  is  examined,  reduce_mode  1  proceeds  to  a  series  of  five  calls  to  the  crunch 
procedure.  Recall  that  crunch  performs  model  reduction  according  to  a  specified  type 
of  Ada  construct.  This  procedure  is  called  once  for  each  of  the  following  constructs: 
I  oops  (basic),  for  .  .  I  oops,  uih  i  1  e  .  .  I  oops,  i  f  constructs,  and  case  constructs. 
After  model  reduction  is  complete,  reduce_mode  I  terminates  and  returns  the  final 
model  to  its  parent  procedure. 

The  reduce_mode  I  procedure  is  called  in  two  types  of  situations.  First,  it  is 
called  each  time  the  source  code  processing  completes  a  subprogram  model,  and  it  is 
invoked  from  the  procedure  called  end-found.  The  subprogram  model  returned  by 
reduce_mode  I  is  stored  in  the  procedures  data  structure  for  later  reference.  The 
second  situation  involves  model  analysis  for  a  single  application  task.  After  an 
application  task  model  is  constructed,  task-parse  submits  it  to  a  procedure  called 
f  i  nd_utor3t_pat  h,  which  is  responsible  for  reducing  a  task  model  to  a  single 
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parameter  set  representing  the  worst  case  execution  path,  f  i  nd_uior3t_pat  h  begins 
by  calling  upon  reduce_mode  I  to  perform  model  preparation  and  reduction.  It  then 
examines  the  resulting  model  to  find  all  WFS  entries.  Since  a  single  cycle  execution  path 
must  begin  and  end  at  a  call  to  uta  i  t_f  or_3chedu  I  e,  f  i  nd_u)orst_pat  h  uses  the 
list  of  WFS  entries  as  starting  points  for  “mode  2”  path  analyses.  For  each  WFS  entry, 
f  i  nd-uiorst—pat  h  calls  upon  generat  e_pat  hs  to  perform  a  “mode  2”  analysis 
using  that  entry  as  the  starting  point.  generate_path3  returns  the  parameter  set 
representing  the  worst  case  path  beginning  from  the  specified  WFS  entry,  and 
f  i  nd_uiorst_pat  h  compares  the  parameter  sets  returned  fui  all  WFS  entries.  The 
result  is  a  single  worst  case  parameter  set  that  is  used  to  represent  the  entire  application 
task  for  the  remainder  of  the  timing  analysis,  f  i  nd_uior3t_pat  h  returns  the  parameter 
set  to  its  parent  procedure,  task-parse,  and  the  software  analysis  for  that  application 
task  is  then  complete. 
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Chapter  8 

Hardware  Model  Analysis 


8.1  Introduction 

The  hardware  model  analysis  is  the  last  of  the  three  phases  of  the  AFTA  timing 
analysis.  The  fundamental  output  of  the  first  two  phases  (preliminary  processing  and 
software  analysis)  is  a  collection  of  worst  case  delay  parameterizations  —  one  for  each 
task  instantiation  in  the  task  suite.  The  primary  function  of  the  hardware  analysis  is  to 
examine  these  parameterizations  with  reference  to  the  AFTA  system  configuration  in 
order  to  predict  performance  failures.  In  this  role,  the  hardware  analysis  is  essentially  an 
integration  phase,  for  it  utilizes  models  of  the  rate  group  scheduling  system  and  the 
AFTA  virtual  group  configuration  in  performing  a  comprehensive  examination  of  the  task 
models.  During  the  software  analysis,  task  models  are  developed  and  analyzed  strictly  on 
an  individual  basis  in  an  effort  to  quantify  a  single  worst  case  execution  delay  for  each 
task  instantiation.  In  contrast,  the  hardware  analysis  views  tasks  collectively  according  to 
their  virtual  group  designations,  and  it  uses  known  performance  characteristics  of  the 
operating  system  to  determine  if,  under  worst  case  conditions,  the  task  groupings  as  a 
whole  can  satisfy  the  hard-real-time  constraints  of  the  rate  group  scheduling  system.  A 
discussion  of  this  process  begins  with  Section  8.4. 

A  second  function  of  the  hardware  analysis  involves  calculation  of  a  lower  bound 
delay  value  for  a  given  execution  path.  The  results  of  this  calculation  are  needed  by  the 
software  analysis  to  effectively  compare  different  execution  paths  through  the  same  code 
model  and  thereby  identify  the  worst  case  path  through  that  model.  This  function  is  so 
closely  associated  with  the  software  analysis  that  it  is  difficult  to  distinctly  classify  it  as 
part  of  the  hardware  analysis,  but  since  it  depends  heavily  upon  knowledge  of  system 
specific  delays,  it  is  best  to  discuss  this  calculation  process  in  conjunction  with  other 
hardware-related  analyses.  This  process  is  presented  in  Section  8.3. 

8.2  Benchmarking 

The  timing  behavior  of  a  hard-real-time  system  is  critical  to  its  success,  and  a 
proper  understanding  of  the  timing  behavior  enables  the  user  to  maximize  a  system’s 
performance  without  compromising  its  effectiveness.  To  this  end,  Draper  Lab  is 
conducting  a  thorough  study  of  the  AFTA’s  performance  characteristics,  and  the  results 
to  date  are  reported  in  [CLAS93].  The  objectives  of  the  performance  measurement  study 
are  as  follows: 


89 


1.  To  develop  analytical  models  useful  in  predicting  system  performance  under 
various  configurations  and  workloads  [CLAS93]. 

2.  To  be  able  to  quantify  system  overhead  on  a  frame  by  frame  basis  in  order  to 
calculate  the  time  available  for  application  tasks  [CLAS93]. 

3.  To  identify  potential  performance  bottlenecks  so  that  they  are  eliminated  in  a 
cost-effective  manner  at  an  early  stage  of  development  [CLAS93], 

The  first  two  objectives  listed  above  are  closely  related  to  the  goals  of  the  AFTA  timing 
analysis.  The  execution  model  that  has  emerged  from  the  performance  measurement 
study  is  used  by  the  hardware  analysis  to  examine  the  timing  behavior  of  virtual  groups 
within  the  confines  of  rate  group  scheduling.  Also,  the  actual  performance  measurement 
data  enables  the  timing  analysis  to  quantify  both  overhead  and  application  task  delays  for 
a  particular  virtual  group  on  a  frame  by  frame  basis.  It  is  these  calculations  that  lead  to 
the  final  performance  failure  predictions. 

Figure  8-1  shows  a  model  of  the  operating  system  overhead  involved  in  each 
minor  frame.  This  figure  is  not  drawn  to  scale  and  is  intended  to  illustrate  the 
chronological  progression  of  overhead  tasks  relative  to  scheduled  interrupts. 


Frame  Timer  I/O  Completion  Frame  Timer 

Interrupt  Interrupt  Interrupt 


I/O  transactions  y 

queued  message  passing 


Figure  8-1,  Minor  Frame  Overhead  Model  [CLAS93] 

Each  minor  frame  begins  with  a  hardware-generated  timer  interrupt  that  is  scheduled  by 
the  operating  system,  and  the  frame  time  is  partitioned  into  two  sections  by  a  second 
timer  interrupt  known  as  the  I/O  completion  interrupt.  The  first  portion  of  the  frame  is 


dedicated  to  operating  system  functions  and  I/O  operations,  and  the  second  portion  is 
filled  with  another  round  of  operating  system  functions  followed  by  user  application  task 
time.  Notice  that  the  amount  of  processing  time  allotted  to  the  application  task  suite  is 
clearly  affected  by  the  amount  of  time  dedicated  to  operating  system  overhead  within  the 
second  portion  of  the  frame.  The  software  analysis  determines  how  much  time  an 
application  task  requires  under  worst  case  conditions;  the  hardware  analysis  then  groups 
tasks  according  to  their  designated  VGs  and  further  calculates  worst  case  operating 
system  overhead  for  each  VG  within  each  minor  frame.  The  total  of  all  required 
processing  times  for  a  particular  virtual  group  is  then  compared  against  the  time  allotted 
for  the  second  portion  of  the  minor  frame  to  determine  if  a  performance  failure  could 
occur.  In  simple  terms,  a  performance  failure  indicates  that  the  second  portion  of  one 
minor  frame  overlaps  into  the  first  portion  of  the  next  minor  frame.  This  type  of  “overrun 
check”  is  the  main  thrust  of  the  hardware  phase  of  the  AFTA  timing  analysis,  but  it  is 
important  to  notice  that  a  second  type  of  overrun  condition  can  also  occur.  If  the 
operating  system  overhead  within  the  first  portion  of  the  frame  exceeds  its  allotted  time,  it 
overlaps  into  the  second  portion  of  the  frame.  This  type  of  overrun  is  heavily  dependent 
upon  the  activity  of  the  I/O  dispatcher,  but  at  this  point  in  the  AFTA’s  development,  the 
implementation  of  I/O  operations  is  not  well-defined.  As  such,  the  current  timing 
analysis  does  not  attempt  to  quantify  the  I/O  dispatcher  execution  delay  or  predict  this 
form  of  intraframe  overrun. 

The  following  paragraphs  give  a  brief  description  of  the  various  overhead  tasks 
that  are  executed  as  part  of  each  minor  frame.  A  simple  equation  is  included  with  each 
task  description  to  indicate  how  much  frame  time  the  task  occupies  and  what  variables 
affect  its  execution  delay.  These  equations  are  taken  from  [CLAS93],  and  they  are  based 
upon  data  taken  during  AFTA  performance  measurement  study. 

IHi:  The  interrupt  handler  updates  the  current  time  value  held  by  each  member  of 
the  virtual  group.  For  fault-tolerant  operation,  it  is  critical  that  all  VG  members  maintain 
the  same  clock  value,  and  this  time  update  serves  to  eliminate  clock  skew.  The  interrupt 
handler  also  schedules  the  next  interrupt  time,  which  in  this  case  is  the  I/O  completion 
interrupt.  The  most  time  consuming  portion  of  the  interrupt  handler  is  the  message 
scoop.  This  involves  the  transfer  of  all  message  packets  destined  for  the  VG  from  the 
network  element’s  dual  port  RAM  to  the  local  memory  space  of  the  individual  members 
of  the  VG.  The  delay  incurred  by  the  scoop  process  varies  according  to  the  number  of 
packets  added  to  the  virtual  group’s  network  element  input  buffers  since  the  last  scoop. 

IH i  =  (110*  number  of  jackets)  +  103  (ftsec) 
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RGDj:  This  is  the  first  of  two  manifestations  of  the  rate  group  dispatcher.  Its  first 
function  is  to  establish  a  constant  time  reference  for  each  of  the  various  rate  groups  whose 
frame  boundaries  coincide  with  the  beginning  of  the  current  minor  frame.  This  reference 
is  set  to  the  congruent  clock  value  established  by  the  interrupt  handler  at  the  beginning  of 
the  frame,  and  it  ensures  that  all  members  of  a  VG  use  identical  values  for  any  time-based 
calculations  executed  within  the  application  tasks.  For  the  present  rate  group 
designations,  the  RG4  reference  value  is  updated  every  minor  frame,  whereas  for  RG 1 , 
this  value  is  updated  only  once  every  eight  minor  frames.  Refer  to  Figure  8-2  (page  98) 
for  an  illustration  of  the  rate  group  frame  organization  and  frame  boundaries.  The  second 
function  of  the  rate  group  dispatcher  is  to  check  for  overrun  conditions.  It  first  looks  for 
an  overrun  on  the  most  recent  execution  of  the  rate  group  dispatcher,  and  then  it  checks 
for  overruns  on  any  tasks  that  were  scheduled  to  complete  within  the  previous  minor 
frame.  The  overrun  checking  occupies  the  majority  of  the  time  for  the  RGD,  and  its 
delay  is  a  function  of  the  number  of  application  tasks  that  were  supposed  to  complete 
within  the  last  minor  frame.  The  longest  delay  is  incurred  in  minor  frame  0  (refer  to 
Figure  8-2)  because  tasks  in  all  four  rate  groups  are  scheduled  to  complete  in  the 
preceding  minor  frame  (#7).  In  contrast,  the  shortest  delay  is  incurred  in  minor  frames 
1,3,5,  and  7  since  the  RGD  only  monitors  RG4  tasks  within  those  minor  frames. 

RGD i  =  (10*  number  of  suspended  tasks)  +  69  (psec) 

IOD:  The  I/O  dispatcher  is  responsible  for  handling  all  I/O  requests.  It  begins  by 
initiating  all  requested  outgoing  data  transmissions  and  then  waits  for  a  predetermined 
time  period  to  allow  for  completed  transmission  of  all  data.  Following  this  idle  period, 
the  IOD  begins  reading  in  any  received  data,  and  the  duration  of  this  task  is  a  function  of 
the  number  of  input  requests  and  the  total  amount  of  data  transmitted.  At  this  stage  of  the 
AFTA  design,  the  I/O  operations  are  not  fully  refined,  and  the  delay  incurred  by  the  IOD 
has  not  been  accurately  measured  or  analyzed.  As  such,  the  AFTA  timing  analysis 
presently  overlooks  all  execution  delay  incurred  by  I/O  operations  and  related  operating 
system  overhead.  It  will  be  a  feasible  task  to  later  include  such  considerations  in  future 
revisions  of  the  timing  analysis. 

IH2:  The  execution  of  the  interrupt  handler  in  the  second  portion  of  the  minor 
frame  is  identical  to  that  which  occurs  in  the  first  portion  of  the  frame.  This  second 
execution  serves  to  scoop  all  message  packets  delivered  for  the  VG  since  the  previous 
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execution  of  the  interrupt  handler.  The  use  of  two  scoop  operations  within  the  same 
minor  frame  is  needed  to  maintain  synchronization  between  members  of  the  same  VG. 
IHi  -(110*  number  of  jpackets)  +  103  (psec) 


RGD2:  The  second  part  of  the  rate  group  dispatcher  is  responsible  for  a  number 
of  functions.  It  begins  by  checking  for  overrun  conditions  on  the  first  part  of  the  RGD 
and  on  the  preceding  execution  of  the  I/O  dispatcher.  This  is  followed  by  the 
3end_queue  and  update_queue  functions.  Together  these  functions  perform  a  data 
transfer  of  all  message  packets  that  were  queued  by  tasks  which  completed  their 
execution  cycles  during  the  previous  minor  frame.  The  delay  incurred  by  these  functions 
therefore  varies  according  to  the  number  of  tasks  whose  messages  require  transfer  as  well 
as  the  size  of  those  messages.  A  summary  equation  is  given  below: 

Send  and  Update  Queue  (per  task)  =  (123  *  number  of  _packets)  -  12  (psec) 
Following  the  message  passing  operations,  the  RGD  schedules  all  rate  group  tasks  whose 
frame  boundary  coincides  with  the  beginning  of  the  current  minor  frame.  For  example, 
during  minor  frame  0,  the  RGD  schedules  all  rate  group  tasks  since  all  rate  group  frames 
begin  anew  with  minor  frame  0.  In  contrast,  during  minor  frames  1,3,5,  and  7.  the  RGD 
only  schedules  RG4  tasks  because  no  other  rate  group  frames  begin  with  these  minor 
frames.  A  summary  of  the  delay  incurred  by  task  scheduling  is  shown  below-: 

Schedule JT asks  (per  Rate  Group )  =  (26  *  number  of  rg tasks  )  +  15  (psec) 

By  combining  the  two  previous  equations  and  adding  a  constant  delay  incurred  by  the 
overrun  checking  and  other  minor  functions,  the  total  delay  for  the  second  part  of  the  r;  te 
group  dispatcher  is  summarized  as  follows: 

numjsk  num  rg  isk 

RGD2  =  X  1(87*  num  j)ktf  +  27j  +  X  [26  *  numjgtskj  +151  +  49  (pscci 

i =1  i=l 


where:  numjsk 
num  pktt 
numrgtsk 
numrgtsk, 


is  the  number  of  tasks  that  completed  execution  cycles 
during  the  previous  minor  frame, 
is  the  number  of  packets  that  task  i  queued  during  its 
previous  execution  cycle. 

is  the  number  of  rate  groups  whose  frame  boundary 
coincides  with  the  beginning  of  the  current  minor  frame, 
is  the  number  of  tasks  belonging  to  rate  group  i 


FDIR:  The  fault  detection  identification  and  recovery  task  is  the  software 
complement  to  the  AFTA’s  hardware  redundancy  and  fault  masking  capabilities.  Local 
FDIR  enables  a  virtual  group  to  monitor  itself  and  potentially  perform  some  recovery 
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operation.  It  is  executed  on  all  virtual  groups  and  its  execution  delay  is  a  known  constant 
of  84  fisec.  System  FDIR  allows  the  AFTA  to  monitor  the  global  system  and  to 
determine  the  health  of  shared  components  such  as  the  network  elements  |AFTA91 1.  It 
executes  as  an  RG4  task  on  a  single  redundant  VG  known  as  the  system  VG.  In  its 
present  developmental  state,  system  FDIR  incurs  a  1316  |isec  delay. 

IOSC:  The  I/O  source  congruency  manager  ensures  that  all  members  of  a  virtual 
group  receive  identical  copies  of  any  input  value  read  by  one  or  more  members  of  the 
group.  This  involves  complete  message  passing  operations,  and  the  d^’  ty  incurred  is  a 
function  of  the  number  of  I/O  input  values  as  well  as  the  number  of  VG  members 
receiving  these  values  from  external  systems  (most  likely  one  member  or  all  members). 
Since  the  AFTA’s  I/O  capabilities  are  not  yet  refined  and  ready  for  testing,  there  is  no 
data  on  this  source  of  overhead. 

IOP:  The  I/O  processing  task  resolves  multiple  input  values  into  a  single  quantity 
that  is  used  by  all  members  of  the  VG.  Suppose  that  each  member  of  a  triplex  VG  is 
interfaced  with  an  external  air  temperature  sensor.  It  is  not  likely  that  all  three  sensors 
would  return  identical  values  to  their  respective  processors,  and  it  is  therefore  necessary 
for  the  IOP  to  implement  some  algorithm  for  data  resolution.  The  IOP  is  not  fully 
implemented  at  this  time,  but  initial  measurements  show  that  the  minimal  IOP  overhead 
is  15|isec. 

In  addition  to  overhead  evaluation,  the  performance  measurement  study  also 
focuses  on  operating  system  functions  related  to  user  application  tasks.  For  example,  data 
has  been  taken  to  determine  the  amount  of  delay  required  for  a  context  switch,  which 
occurs  every  time  a  task  completes  an  execution  cycle  and  suspends  itself  so  that  the  next 
scheduled  task  can  begin  execution.  Results  indicate  that  the  average  context  sw  itch 
requires  19  jisec.  Naturally,  the  amount  of  time  devoted  to  context  switching  varies 
according  to  the  number  of  tasks  that  complete  execution  during  a  given  minor  frame. 
For  the  sake  of  this  analysis,  it  is  assumed  that  all  rate  group  tasks  complete  execution 
during  the  last  minor  frame  of  their  respective  rate  group  frames.  For  instance,  it  is 
assumed  that  RG1  tasks  complete  execution  during  minor  frame  7,  and  RG2  tasks 
complete  their  cycles  during  minor  frames  3  and  7. 

The  most  time  consuming  operating  system  calls  utilized  by  application  tasks  are 
the  message  passing  functions.  Evaluations  of  these  operations  yield  the  following 
results: 
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queue-message  =  (45  *  num_msg_packets )  +  43  nsec 
retrieve-message  =  (61  *  nummsgjjackets)  +  67 nsec 
These  functions  are  closely  related  to  a  few  of  the  overhead  tasks  described  previously. 
The  queue-message  procedure  is  used  by  the  application  task  to  prepare  a  message  for 
exchange  over  the  AFTA  optical  network  and  to  transfer  the  packets  to  the  processor’s 
local  memory.  The  send_queue  procedure  is  later  activated  by  the  rate  group 
dispatcher  and  transfers  the  message  packets  from  local  memory  to  the  dual  port  RAM 
buffers  on  the  NE.  It  is  important  to  maintain  the  distinction  between  these  two 
operations,  for  queue-message  occupies  application  task  execution  time  while 
send— queue  occupies  RGD  overhead  time.  The  contributions  of  these  two  delays 
occur  during  different  minor  frames  and  therefore  are  not  considered  as  a  single  delay 
entity,  although  the  operations  are  actually  performed  on  the  same  message  packets. 
Similarly,  ret  r  i  eue_mes3age  is  closely  related  to  the  scoop  message  operation 
included  in  the  interrupt  handler.  The  IH  scoop  transfers  message  packets  from  the  NE 
message  buffers  to  the  processor’s  local  memory;  ret  r  i  eue_me33age  reconstructs  the 
message  from  the  packets  stored  in  local  memory  and  delivers  it  to  the  appropriate 
application  task.  Once  again,  these  operations  are  performed  on  the  same  message 
packets  but  occur  during  different  minor  frames.  Thus,  the  corresponding  delays  are 
considered  independently. 

8.3  Path  Comparison  Calculation 

For  each  instantiation  of  an  application  task,  the  software  analysis  generates  all 
possible  execution  paths  through  the  appropriate  task  model.  In  order  to  determine  which 
path  represents  the  worst  case  delay,  there  must  be  a  quantitative  comparison  of  the 
individual  paths,  and  the  necessary  calculations  require  the  system  specific  delay  data 
discussed  in  the  previous  section.  As  part  of  the  path  generation  process. 
generate_paths  calls  upon  ca  1  cu  I  ate_t  i  me  to  produce  a  single  delay  value  to 
represent  each  complete  execution  path.  calculate_time  uses  the  path 
parameterization  produced  by  parameter  i  ze  in  combination  with  the  list  of  constants 
derived  from  the  performance  measurement  study  to  return  a  single  integer  value  that 
represents  the  lower  bound  on  execution  delay  for  the  given  path,  generat  e_pat  hs 
then  compares  this  value  to  the  values  for  the  previous  execution  paths  to  identify  the 
worst  case  path. 

ca  I  cu  I  ate_t  i  me  is  essentially  a  simple  series  of  algebraic  manipulations  that 
transforms  a  path  parameterization  into  a  tangible  time  value.  At  the  beginning  of  the 
timing  analysis,  the  read- 1  i  3t  procedure  develops  a  list  of  system  specific  constants 
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and  coefficients  by  reading  integer  values  from  the  file  called  “constants.dat”  and  storing 
them  in  the  data  structure  called  de  I  ay_dat  a.  All  values  are  in  terms  of  nsec  and  are 
derived  from  the  AFTA  benchmarking  efforts.  Note  that  these  values  are  intentionally 
stored  in  an  external  file  to  be  read  at  run-time  so  that  any  future  changes  to  the 
benchmarking  results  do  not  force  a  recompilation  of  the  timing  analysis  code.  The 
integers  held  in  de  I  ay_dat  a  correspond  to  the  coefficients  and  constants  listed  in  the 
delay  equations  of  Section  8.2,  and  they  also  directly  relate  to  the  various  elements  of  the 
path  parameterization.  Given  the  proper  constants  and  the  necessary  path  parameters, 
ca  I  cu  I  ate_ t  i  me  simply  applies  the  given  equations  to  arrive  at  the  lower  bound  on 
execution  delay.  The  present  list  of  path  parameters  is  quite  limited,  and  the  same  is  true 
for  the  integer  list  held  in  de  I  ay_data;  however,  as  the  AFTA  prototyping  and 
benchmarking  efforts  progress,  the  parameter  list  will  expand  and  the  list  of  constants 
will  grow  accordingly.  The  timing  analysis  code  is  designed  specifically  to  allow  for 
such  growth,  and  Appendix  G  outlines  the  process  of  adding  new  elements  to  the  list  of 
path  parameters.  As  the  AFTA  project  progresses  and  the  timing  analysis  is  revised, 
ca  I  cu  I  ate_t  i  me  will  account  for  a  broader  range  of  delay  factors  and  the  values  it 
returns  will  become  more  accurate. 

8.4  Organizing  Application  Tasks 

The  fundamental  goal  of  the  hardware  model  analysis  is  to  successfully  integrate 
the  results  of  the  software  analysis  with  the  established  system  delay  data  in  order  to 
predict  potential  performance  failures.  Whereas  the  software  analysis  evaluates 
application  tasks  purely  on  an  individual  basis,  the  hardware  analysis  deals  with  tasks 
collectively  according  to  their  virtual  group  assignments.  As  such,  the  virtual  group 
serves  as  the  basic  unit  of  analysis  in  this  final  phase,  and  the  first  objective  is  to  properly 
categorize  the  application  tasks  according  to  the  given  system  configuration. 

The  preliminary  processing  phase  (Chapter  3)  produces  a  file  called 
“list_of_tasks.dat,”  which  contains  the  complete  AFTA  software  configuration.  The  file 
is  organized  so  that  each  task  instantiation  is  listed  on  a  single  line  along  with  the 
appropriate  virtual  group  and  rate  group  specifications  and  message  passing  limitations. 
Multiple  instantiations  of  the  same  task  are  treated  as  distinct  entities  in  order  to  simplify 
the  task  organization  process  and  to  allow  for  separate  software  analyses  of  the  same  task 
code  with  potentially  different  message  passing  limitations.  The  procedure  called 
process— I  i  si  is  responsible  for  reading  the  configuration  file  and  sorting  the  tasks 
into  an  array  of  40  virtual  groups.  It  is  important  to  note  that  the  software  analysis  is 
actually  initiated  within  this  sorting  process,  for  as  each  task  is  taken  from  the 
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configuration  file  and  placed  in  the  proper  VG,  it  is  submitted  to  t  ask_par  se,  which 
returns  the  worst  case  delay  parameterization  for  the  given  task  instantiation.  Information 
about  each  virtual  group  is  stored  in  a  relatively  extensive  data  structure;  what  follows  is 
a  detailed  description  of  each  element  in  the  structure: 

1.  present :  A  boolean  variable  to  indicate  if  a  particular  VG  exists  within  the 
given  system  configuration.  The  AFTA  allows  up  to  40  VGs  within  its 
configuration,  but  it  is  not  likely  that  most  configurations  will  utilize  all  the 
VGs.  Therefore,  this  “presence  bit”  simplifies  processing  by  signaling  the 
analysis  to  ignore  all  non-existent  VGs. 

2.  overrun:  This  is  a  one  dimensional  array  of  integers  that  is  established  by 
the  over run_check  procedure.  For  every  timing  deadline  that  is  not 
satisfied  in  the  worst  case  analysis,  a  particular  integer  is  stored  in  this  array  to 
indicate  the  nature  of  the  performance  failure.  Section  8.4  explains  this 
seemingly  cryptic  form  of  information  storage. 

3.  num—taska:  An  array  of  five  integers  used  to  establish  the  number  of 
application  tasks  resident  in  each  of  the  four  rate  groups  on  the  given  VG. 
Note  that  the  fifth  integer  is  simply  a  sum  of  the  other  four  and  thus  indicates 
the  total  number  of  tasks  associated  with  the  virtual  group. 

4.  tasks:  An  array  of  task-based  data  structures.  For  each  task  instantiation 
belonging  to  the  virtual  group,  this  structure  stores  the  name,  rate  group 
specification,  and  worst  case  execution  path  parameterization.  It  is  the 
development  of  this  element  of  the  virtual  group  structure  that  initiates  the 
software  analysis  for  each  task  in  the  suite. 

5.  r  g_t  ot  a  Is:  An  array  of  four  integers  that  tracks  the  cumulative  delay  for 
tasks  within  each  of  the  four  rate  groups.  As  a  task  is  added  to  its  respective 
virtual  group,  its  worst  case  delay  value  is  added  to  the  total  for  its  respective 
rate  group.  In  other  words,  r g_t  ot  a  I  f  1  ]  contains  the  cumulative  worst  case 
delay  for  all  RG1  tasks  within  the  VG. 

6.  msg_total  s:  A  four  element  array  of  integer  pairs  that  tracks  the 
cumulative  message  traffic  for  each  of  the  four  rate  groups.  This  information 
is  required  in  calculating  the  overhead  for  each  of  the  eight  minor  frames  since 
the  rate  group  dispatcher  delay  is  a  function  of  the  rate  group  message  traffic. 

As  each  task  is  added  to  the  VG,  its  queued  message  parameters  are  added  to 
the  appropriate  msg_total3  integer  pair.  The  first  integer  of  the  pair 
indicates  the  number  of  messages  queued  for  the  given  rate  group  during  a 
single  execution  cycle  (under  worst  case  conditions),  and  the  second  integer 
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denotes  the  total  number  of  packets  queued  for  that  RG  during  one  execution 
cycle.  Note  that  message  traffic  is  tracked  only  according  to  the  number  of 
messages  queued,  while  the  messages  retrieved,  sent,  and  read  during  an 
execution  cycle  are  effectively  ignored.  Section  8.6  addresses  the  assumptions 
involved  in  focusing  only  upon  queued  message  traffic. 

Once  the  information  in  “list_of_tasks.dat”  is  exhausted,  the  virtual  group  records  are 
considered  complete,  and  the  actual  timing  calculations  begin. 

8.5  Predicting  Performance  Failures 

The  procedure  called  ouerr un_check  is  responsible  for  the  final  timing 
calculations  in  the  hardware  analysis  phase.  The  objective  of  these  calculations  is  to 
predict  potential  failures  to  satisfy  the  hard-real-time  constraints  imposed  by  the  AFTA's 
rate  group  scheduling  paradigm.  In  more  concrete  terms,  the  overrun  check  attempts  to 
identify  possible  situations  in  which  the  combined  delays  of  system  overhead  and 
application  task  execution  exceed  the  time  allotted  within  the  second  portion  of  any  minor 
frame  (refer  to  Figure  8- 1 ). 

Under  the  present  rate  group  configuration,  an  80ms  time  slice  contains  at  least 
one  full  iteration  of  the  tasks  in  all  four  rate  groups,  and  as  illustrated  in  Figure  8-2,  it  is 
comprised  of  8  unique  minor  frames,  each  of  which  follows  the  execution  pattern 
described  in  Section  8.2.  Since  the  80ms  time  slice  contains  at  least  one  frame  boundary 
for  each  rate  group,  all  relevant  timing  constraints  can  be  validated  through  a  timing 
analysis  that  is  limited  to  a  set  of  8  contiguous  minor  frames  which  spans  a  single  RGl 
frame,  as  shown  below: 


minor  frame  index: 
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Figure  8-2,  Rate  Group  Frame  Organization 


Since  this  analysis  deals  with  worst  case  scenarios,  it  is  naturally  assumed  that  if 
timing  deadlines  are  satisfied  for  a  single  complete  time  slice,  they  are  satisfied  for  all 
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time.  For  every  virtual  group,  the  overrun  check  attempts  to  determine  if,  under  worst 
case  conditions,  the  tasks  within  each  rate  group  can  complete  execution  prior  to  the 
appropriate  frame  boundaries.  Figure  8-3  (page  101)  illustrates  the  deadlines  that  must  be 
considered  in  such  an  analysis.  For  each  minor  frame,  all  overhead  tasks  and  RG4  tasks 
within  a  given  virtual  group  must  complete  a  single  execution  cycle.  Any  remaining  time 
within  the  minor  frame  is  dedicated  to  scheduled  tasks  within  the  other  rate  groups. 
Notice  that  higher  numbered  rate  groups  have  execution  precedence  over  lower  numbered 
groups,  and  until  all  tasks  belonging  to  a  higher  priority  rate  group  complete  their 
execution  cycles,  tasks  within  lower  priority  rate  groups  are  not  granted  any  frame  time. 
At  each  minor  frame  boundary,  execution  priority  returns  to  the  overhead  and  RG4  tasks. 
A  mathematical  summary  of  these  timing  constraints  accompanies  Figure  8-3  as  a  list  of 
15  inequalities.  If  all  15  inequalities  are  satisfied,  the  timing  deadlines  are  satisfied. 

Evaluating  the  inequalities  themselves  is  a  trivial  task.  What  is  important  here  is 
to  explain  the  elements  involved  in  the  calculations  and  the  rationale  behind  the 
inequalities.  The  first  priority  of  overrun- check  is  to  evaluate  the  delay  due  to 
system  overhead  in  the  second  portion  of  each  of  the  eight  minor  frames.  As  discussed  in 
Section  8.2,  this  value  is  based  on  the  sum  of  the  following  factors: 

1.  IH2  =  (110*  number  of  jackets)  +  103  (nsec) 

numjsk  num_rg  tsk 

2. RGD2  =  X  1(87  *  num _pkti)  +  27]  +  X  [(26  *  num _rg _t.sk,)  +  15/  +  49  (nsec) 

i =1  i  =1 

3.  context  switches  =19  nsec  each 

4.  local  FD1R  =  84  nsec 

For  each  of  the  equations  above,  it  is  important  to  understand  that  this  analysis 
assumes  that  rate  group  tasks  always  complete  their  execution  cycles  during  the  last 
minor  frame  prior  to  their  respective  frame  boundaries.  For  instance,  it  is  assumed  that 
all  RG1  tasks  complete  execution  during  minor  frame  7,  and  it  is  assumed  that  all  RG2 
tasks  complete  execution  cycles  during  minor  frames  3  and  7.  This  type  of  assumption 
creates  a  worst  case  scenario  for  the  system  overhead  because  the  burden  of  message 
passing  operations  imposed  by  the  various  rate  groups  is  thereby  concentrated  in  the 
minor  frames  that  follow  common  frame  boundaries,  rather  than  being  evenly  distributed 
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among  all  eight  minor  frames.  The  same  concept  applies  to  the  overhead  imposed  by 
context  switching  and  the  overrun  checking  performed  by  the  rate  group  dispatcher. 

For  the  first  overhead  equation  shown  above,  the  variable  called 
number  of  jackets  is  based  upon  the  values  stored  in  the  msg_t  ot  a  I  3  element  of  the 
VG  record.  In  calculating  the  overhead  for  minor  frame  0,  number  of  jackets  is  a  sum 
of  the  packets  queued  by  all  four  rate  groups  because  it  is  assumed  that  all  application 
tasks  complete  execution  cycles  during  the  previous  minor  frame.  In  a  similar  manner, 
when  calculating  the  overhead  for  minor  frame  6,  number  of  jackets  is  based  upon  the 
msg_tota  I  s  values  for  RG3  and  RG4  tasks,  since  both  of  these  groups  complete 
execution  cycles  during  minor  frame  5.  The  same  principles  apply  in  the  second  equation 
when  calculating  num  jkti  and  num_tsk  for  each  minor  frame.  Also  included  in  the  rate 
group  dispatcher  equation  is  the  overhead  for  overrun  checking.  This  requires  that  within 
each  minor  frame,  the  RGD  checks  the  status  of  all  tasks  that  should  have  been  completed 
within  the  previous  minor  frame.  Figure  8-3  indicates  how  the  frame  boundaries  affect 
various  minor  frames,  and  the  information  contained  in  the  VG  record  is  sufficient  to 
determine  the  number  of  tasks  to  be  checked  by  the  RGD  in  a  given  minor  frame.  The 
evaluation  of  context  switching  overhead  follows  the  same  rules  as  used  with  the 
overhead  for  overrun  checking.  Lastly,  local  FDIR  affects  all  minor  frames  and  is 
appropriately  added  as  a  simple  delay  constant.  As  the  minor  frame  overhead  values  are 
calculated,  they  are  stored  in  an  eight  element  array  of  integers  called  OH[  ]. 

The  first  eight  inequalities  ensure  that  the  RG4  tasks  meet  their  timing  deadlines 
in  each  of  the  eight  minor  frames.  They  simply  compare  the  sum  of  overhead  delay  and 
RG4  task  delay  to  the  amount  of  time  allotted  within  the  second  portion  of  the  minor 
frame.  The  next  group  of  four  inequalities  ensures  that  RG3  tasks  complete  their 
execution  cycles  without  exceeding  their  frame  boundaries.  These  calculations  account 
for  delays  due  to  overhead  and  RG4  task  execution  to  determine  if  there  is  sufficient 
frame  time  left  over  for  the  lower  priority  RG3  tasks.  The  next  two  inequalities  are 
dedicated  to  validating  the  two  frame  boundaries  encountered  by  RG2  tasks,  and  the  last 
inequality  ensures  that  RG1  tasks  meet  their  timing  deadlines.  Notice  that  the 
calculations  for  each  rate  group  account  for  delays  due  to  all  tasks  with  higher  priorities 
while  ignoring  delays  incurred  by  tasks  with  lower  priorities.  The  inequalities  are 
numbered  1  through  15,  and  the  integer  correspond. ng  to  each  inequality  that  is  not 
satisfied  is  stored  in  the  ooerrun  array  of  the  VG  record. 
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Figure  8-3,  A  Simplified  View  of  Rate  Group  Scheduling 


1:  OH(0)  +  RG4  <  1  minor  frame 

2:  OH(l)  +  RG4  <  1  minor  frame 

3:  OH(2)  +  RG4  <  1  minor  frame 

4:  OH(3)  +  RG4  <  1  minor  frame 

5:  OH(4)  +  RG4  <  1  minor  frame 

6:  OH(5)  +  RG4  <  1  minor  frame 

7:  OH(6)  +  RG4  <  1  minor  frame 

8:  OH(7)  +  RG4  <  1  minor  frame 

9:  OH(O)  +  OH(l)  +  2xRG4  +  RG2  <  2  minor  frames 

10:  OH(2)  +  OH(3)  +  2xRG4  +  RG2  <  2  minor  frames 

1 1 :  OH(4)  +  OH(5)  +  2xRG4  +  RG2  <  2  minor  frames 

12:  OH(6)  +  OH(7)  +  2xRG4  +  RG2  <  2  minor  frames 

13:  OH(0)  +  OH(l)  +  OH(2)  +OH(3)  +  4xRG4  +  2xRG3  +  RG2  <  4  minor  frames 
14:  OH(4)  +  OH(5)  +  OH(6)  +OH(7)  +  4xRG4  +  2xRG3  +  RG2  <  4  minor  frames 
15:  OH(0)  +  OH(l)  +  OH(2)  +  OH(3)  +  OH(4)  +  OH(5)  +  OH(6)  +  OH(7)  + 
8xRG4  +  4xRG3  +  2xRG2  +  RGI  <  8  minor  frames 

OH(x)  refers  to  the  overhead  delay  in  minor  frame  x 

RGx  refers  to  the  cumulative  delay  of  all  tasks  belonging  to  rate  group  x 
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8.6  Assumptions 

Throughout  the  AFTA  timing  analysis,  a  number  of  simplifying  assumptions  are 
introduced  in  an  effort  to  produce  useful  results.  It  is  important  for  the  user  to  understand 
the  nature  of  all  assumptions  made,  for  the  accuracy  of  the  analysis  is  significantly 
affected  by  the  validity  of  the  underlying  assumptions.  The  following  paragraphs  discuss 
the  assumptions  that  play  a  critical  role  in  the  integration  of  the  application  task  models 
with  the  system  specific  delay  data  during  the  hardware  analysis  phase. 

When  the  software  analysis  generates  all  possible  execution  paths  through  a 
particular  code  model,  ca  1  cu  I  at  e_t  i  me  is  used  to  gauge  the  minimal  worst  case  delay 
incurred  by  each  path  so  that  the  paths  can  be  effectively  quantified  and  compared.  In 
order  to  definitively  state  that  Path  A  incurs  a  greater  delay  than  Path  B,  the  delay 
estimates  for  both  paths  must  be  based  upon  the  same  set  of  known  deterministic 
quantities.  This  analysis  assumes  that  for  each  critical  construct  included  in  the  code 
model,  an  exact  delay  value  can  be  added  to  the  time  total  for  an  execution  path  which 
includes  that  construct.  In  other  words,  it  is  assumed  that  a  task  such  as  message  retrieval 
incurs  the  same  amount  of  delay  every  time  it  is  called,  regardless  of  the  nature  of  the 
execution  path.  In  the  future,  the  AFTA  will  feature  multiple  architecture  types  for  PEs, 
and  in  such  a  case,  the  delay  for  a  message  retrieval  task  would  vary  as  a  function  of  the 
VG  on  which  a  task  resides.  However,  for  any  given  task  instantiation,  the  same  critical 
construct  always  contributes  the  same  delay  for  every  possible  execution  path.  The 
underlying  assumption  here  is  that  problems  such  as  network  contention  and  bus 
contention  have  a  negligible  effect  on  the  total  delay  for  a  critical  construct.  The  results 
from  the  performance  measurement  study  indicate  relatively  insignificant  standard 
deviations  for  the  operating  system  functions  and  message  passing  functions  evaluated 
thus  far.  Problems  may  arise  in  the  future  as  the  AFTA’s  performance  limits  are  tested 
and  the  global  message  traffic  increases,  but  at  this  point  it  is  safe  to  assume  a  high  level 
of  determinism  in  regard  to  those  constructs  presently  included  in  the  analysis.  Also.  VG 
phasing  can  be  selected  to  minimize  these  effects. 

A  second  assumption  with  regard  to  system  delays  is  that  the  total  time  required 
for  an  execution  path  increases  monotonically  as  a  function  of  the  frequency  of 
occurrence  for  the  critical  constructs  considered.  In  other  words,  an  increase  in  the 
frequency  of  a  critical  construct  within  an  execution  path  never  results  in  a  decrease  in  the 
total  time  delay  incurred  by  that  path;  likewise,  a  decrease  in  the  frequency  of  a  construct 
does  not  result  in  an  increase  in  time  delay.  This  may  seem  to  be  an  inherent  assumption 
that  need  not  be  stated,  but  the  coupling  of  overhead  delays  with  application  task  delays 
through  the  message  passing  functions  creates  the  possibility  for  unusual  delay  behavior 
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that  should  at  least  be  addressed.  It  is  possible  that  a  particular  combination  of  critical 
constructs  within  a  worst  case  path  could  unexpectedly  improve  the  efficiency  of  the 
overhead  functions  for  the  virtual  group  and  thus  transform  a  worst  case  path  into  a  less 
than  worst  case  path.  Such  unusual  behavior  would  likely  arise  from  some  unforeseen 
system  limitation  which  would  prevent  the  overhead  tasks  from  processing  all  given  data 
and  thus  require  less  frame  time.  Fortunately,  this  type  of  non  deterministic  behavior  has 
yet  to  appear  in  system  testing,  and  the  analysis  presented  here  is  conservative  with 
respect  to  increases  in  efficiency. 

The  final  assumption  to  be  discussed  in  this  section  involves  the  nature  of  the 
global  message  traffic.  For  a  static  analysis,  it  is  impossible  to  anticipate  the  number  or 
the  size  of  messages  that  are  received  by  an  application  task  or  group  of  tasks  within  a 
given  execution  cycle.  As  such,  it  is  assumed  for  this  analysis  that  a  VG  only 
communicates  with  itself  —  in  other  words,  no  inter-VG  communication  is  considered. 
The  result  of  this  assumption  is  that  for  worst  case  evaluations,  the  number  of  message 
packets  scooped  for  an  execution  cycle  is  set  equal  to  the  number  of  packets  queued 
during  that  cycle.  This  type  of  assumption  primarily  affects  overhead  calculations,  and  its 
validity  is  critical  since  the  per-packet  processing  time  is  quite  significant  in  the  delay 
calculation  for  the  interrupt  handler.  The  AFTA  prototype  testing  has  not  yet  addressed 
the  detailed  nature  of  global  message  traffic  under  various  configurations,  and  thus  the 
accuracy  of  this  assumption  cannot  yet  be  gauged.  Future  system  testing  could  call  for 
some  adjustments  to  the  message  scoop  delay  calculations. 

8.6  Final  Output  File 

The  final  output  file  for  the  AFTA  timing  analysis  is  called  “results.dat.’'  It  is 
designed  to  present  the  results  of  both  the  software  and  hardware  analysis  an  efficient  and 
readable  format.  The  results  are  organized  according  to  virtual  groups,  and  for  each  VG 
the  following  information  is  included: 

1.  An  individual  listing  of  each  task  instantiation  that  includes  the  task  name, 
filename,  rate  group  designation,  and  full  worst  case  path  parameterization. 

2.  For  each  of  the  four  rate  groups,  a  total  worst  case  application  task  delay  is 
listed  to  help  the  user  recognize  which  rate  groups  are  overburdened  or 
underloaded. 

3.  For  each  of  the  eight  minor  frames,  the  total  worst  case  overhead  delay  is 
listed. 
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4.  A  matrix  of  delay  values  lists  the  delay  contribution  from  the  overhead  and 
each  of  the  rate  groups  within  each  minor  frame.  This  is  intended  to  help  the 
user  identify  potential  timing  problems  and  the  sources  of  those  problems. 

5.  A  listing  of  all  timing  deadline  violations  as  discovered  through  the  evaluation 
of  the  15  inequalities  discussed  earlier  in  this  chapter. 

The  contents  of  the  results  file  should  reinforce  the  concept  that  this  analysis  tool 
is  not  valuable  solely  for  the  prediction  of  possible  performance  failures;  rather,  the 
overrun  check  is  simply  the  most  comprehensive  result  produced.  The  more  important 
results  are  the  intermediate  values  used  in  performing  the  overrun  check.  These  include 
the  overhead  delay  totals  and  the  worst  case  path  parameterization s  of  the  individual 
application  tasks.  One  of  the  major  goals  of  this  analysis  is  to  properly  characterize  the 
software  tasks  for  timing  estimation,  code  optimization,  and  for  further  analysis  of  global 
message  traffic  and  virtual  group  phasing.  After  a  single  configuration  analysis,  it  should 
be  readily  apparent  what  types  of  changes  need  to  be  implemented  to  improve 
performance  results.  These  changes  might  include  streamlining  application  task  code, 
changing  the  mapping  between  tasks  and  virtual  groups,  varying  the  VG  configuration 
itself,  or  altering  the  rate  group  specification  of  one  or  more  application  tasks.  As  stated 
previously,  the  user  always  must  consider  the  contents  of  the  error  file  when  evaluating 
the  data  in  “results.dat,”  for  both  sources  of  output  from  this  analysis  are  relevant  and 
should  not  be  examined  independently. 
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Chapter  9 

Conclusions/Recommendations 


9.1  Conclusions 

This  thesis  presents  an  automated  timing  analysis  tool  that  is  designed  specifically 
to  characterize  and  evaluate  the  timing  behavior  of  a  given  system  configuration  for  the 
current  AFTA  prototype.  The  preceding  chapters  discuss  a  modular  approach  to  the 
development  of  this  automated  tool,  and  the  accuracy  of  the  timing  analysis  depends  upon 
the  successful  execution  of  each  stage  as  well  as  the  proper  interaction  between  these 
stages.  It  is  appropriate  now  to  consider  independently  the  effectiveness  of  each  part  of 
the  analysis  and  then  critique  the  usefulness  of  the  analysis  tool  as  a  whole. 

1.  Preliminary  processing  is  the  first  stage  of  the  timing  analysis.  Its  goal  is  to 
accurately  describe  the  system’s  hardware  and  software  configuration  through 
an  automated  evaluation  of  the  task  specification  file.  This  portion  of  the 
analysis  is  both  simple  and  successful.  No  further  development  is  required. 

2.  The  accuracy  of  the  analysis  depends  upon  proper  characterization  of  the 
system  overhead  in  terms  of  both  constant  and  variable  delay  elements.  The 
AFTA  performance  measurement  study  addresses  this  task  and  presents  the 
results  to  date,  and  the  timing  ana’/sis  tool  depends  upon  these  results  for 
delay  calculations  and  for  the  proper  approach  to  those  calculations.  Given 
the  state  of  the  AFTA  prototype,  the  overhead  data  is  both  accurate  and 
thorough,  but  it  will  be  necessary  in  the  future  to  study  the  effects  of  I/O 
operations  and  network  loading  on  system  overhead.  Such  results  must  then 
be  incorporated  into  the  timing  analysis  that  is  presented  here. 

3.  The  accuracy  of  this  analysis  also  depends  upon  the  definition  and 
measurement  of  significant  sources  of  deterministic  delays  within  application 
tasks.  At  this  point,  the  estimated  application  task  delays  depend  primarily 
upon  the  presence  of  message  passing  calls  within  the  source  code,  and  this 
focus  is  far  too  limited.  In  the  future,  the  list  of  known  deterministic  delays  or 
“critical  constructs”  must  be  expanded  in  order  to  better  characterize  the  worst 
case  timing  behavior  of  individual  application  tasks.  What  is  important  here  is 
that  this  tool  currently  includes  all  the  necessary  infrastructure  for  expanding 
the  list  of  delay  elements  considered  in  a  static  analysis.  At  this  stage  of 
development,  minimal  marginal  effort  is  required  to  expand  the  list  of  known 
deterministic  delays,  and  this  facilitates  rapid  improvement  in  the  accuracy  of 
the  worst  case  delay  estimates. 
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4.  The  second  stage  of  the  timing  analysis  consists  of  a  static  source  code 
analysis  for  each  application  task  in  the  suite,  and  the  first  phase  of  this 
analysis  involves  the  development  of  source  code  models.  At  present,  the 
modeling  process  is  both  tedious  and  delicate,  but  it  stands  as  proof  that  an 
automated  tool  can  effectively  understand  and  evaluate  the  flow  of  execution 
through  complex  high  level  source  code.  The  approach  to  code  modeling  is 
sound  and  allows  for  a  great  deal  of  flexibility  in  terms  of  the  types  of  delay 
elements  upon  which  to  focus  during  a  static  analysis  and  the  range  of  code 
constructs  that  can  be  analyzed  successfully.  Certainly,  the  modeling 
approach  presented  here  is  valid  for  other  high  level  languages  and  could  also 
be  adapted  to  work  with  assembly  language  code.  The  primary  weakness  in 
this  portion  of  the  analysis  tool  is  the  lack  of  AFTA  application  task  source 
code  with  which  to  test  the  modeling  process.  The  intricacies  of  the  code 
parsing  and  modeling  tools  create  a  great  deal  of  room  for  minor  errors,  and  it 
is  important  to  subject  these  tools  to  rigorous  testing  with  any  relevant  source 
code  that  becomes  available. 

5.  The  second  phase  of  the  software  analysis  involves  the  quantitative  evaluation 
of  the  source  code  models  constructed  for  the  various  application  tasks.  Since 
the  model  conventions  are  well-defined  and  limited  by  design,  this  portion  of 
the  timing  analysis  lends  itself  to  extensive  testing  and  improvement.  Given 
any  valid  model,  the  model  analysis  phase  successfully  finds  all  possible 
execution  paths  and  then  parameterizes,  quantifies,  and  compares  them  in 
order  to  identify  the  worst  case  path.  This  part  of  the  analysis  tool  is  by  far  the 
most  successful,  and  the  principles  involved  and  the  algorithms  developed  can 
easily  be  adapted  to  future  changes  in  the  modeling  conventions  or  the  path 
quantification  process. 

6.  The  final  stage  of  the  analysis  involves  the  integration  of  the  individual  task 
analysts  in  a  manner  that  reflects  the  system  virtual  group  configuration  and 
accurately  characterizes  the  amount  of  variable  minor  frame  overhead  incurred 
by  the  given  task  groupings.  This  part  of  the  analysis  is  relatively  straight 
forward  and  quite  robust,  but  it  is  not  complete.  Due  to  the  absence  of  I/O 
overhead  data,  the  calculations  of  the  hardware  model  analysis  are  not 
completely  accurate.  It  should  be  a  simple  task  to  later  add  the  I/O 
measurement  results  to  the  hardware  model  used  by  this  analysis  tool,  but  until 
then,  one  must  remember  that  the  results  produced  are  somew  hat  incomplete. 
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As  a  whole,  the  analysis  tool  presently  produces  results  of  limited  utility,  but  both 
the  code  infrastructure  and  the  approach  to  an  automated  timing  analysis  are  robust  and 
very  valuable.  All  the  necessary  elements  of  a  successful  analysis  tool  are  present,  but 
there  is  a  need  for  further  development  and  testing. 

9.2  Recommendations  for  Further  Study 

The  following  list  details  recommendations  for  further  development  of  the 
automated  timing  analysis  tool: 

1.  In  order  to  improve  the  accuracy  to  the  worst  case  estimates,  the  list  of  critical 
constructs  must  be  expanded.  As  more  application  task  source  code  becomes 
available,  it  should  be  easy  to  determine  what  types  of  functions  and  Ada 
constructs  significantly  contribute  to  the  execution  delay  of  application  tasks. 
Another  good  source  of  critical  constructs  would  be  the  standard  Ada  libraries. 

If  one  were  to  benchmark  all  the  functions  included  in  those  libraries,  any 
standard  Ada  function  could  be  accounted  for  in  the  software  analysis. 

2.  As  application  task  source  code  is  developed  for  the  AFTA,  it  should  be 
subjected  to  the  code  modeling  tools  presented  here.  Extensive  testing  will 
expose  some  minor  errors  in  the  code  modeling  process,  and  it  is  important  to 
correct  these  problems  as  soon  as  possible. 

3.  When  the  I/O  portion  of  the  AFTA  operating  system  is  fully  developed  and 
tested,  its  timing  characteristics  should  be  measured,  modeled,  and 
incorporated  into  the  hardware  model  analysis.  The  accuracy  of  the  system 
overhead  calculations  depends  upon  knowledge  of  I/O  operations,  and  any 
enhancements  to  t'  ese  calculations  will  improve  the  usefulness  of  the  analysis 
results.  Likewise,  any  I/O  operations  that  typically  appear  in  the  application 
task  source  code  should  be  quantified  and  added  to  the  list  of  critical 
constructs. 

4.  Another  useful  improvement  to  the  overhead  calculations  involves  proper 
characterization  of  the  system’s  global  message  passing  operations.  Presently 
it  is  assumed  that  a  task  receives  the  same  amount  of  message  traffic  that  it 
sends,  and  it  would  be  useful  to  either  validate  this  assumption  or  develop  a 
more  accurate  model  of  global  message  traffic  to  be  incorporated  into  the 
overhead  calculations. 


107 


Appendix  A 
HEADER.H 


/*  This  ia  a  coaaon  header  that  ia  utilized  by  both  START. C  and  FINISH. C  */ 

'include  <atdio.h> 

'include  <ctype.h> 

'include  <atdl ib.h> 

•Include  <atring.h> 

'Include  <aath.h> 

/*  The  following  conatanta  identify  critical  conatructa  and  alao  serge  aa  */ 

/*  indices  to  the  aearch_liat  array.  The  code  refers  to  critical  constructs  */ 

/*  and  aearch_llat  entries  according  to  the  naaes  shown  below.  */ 

'define  UFS  0 

•define  LOOP  1 

•define  IF  2 

•define  ELSE  3 

•define  ELSIF  4 

•define  CASE  5 

•define  UHEN  6 

•define  QUEUE  7 

•define  RETRIEUE  8 

•define  SEND  9 

•define  RERO  10 

•define  TASK  11 

•define  EQUAL  12 

•define  RANGE  13 

•define  PACKAGE  II 

•define  PROC  15 

•define  BEGIN  16 

•define  END  17 

•define  GTIO  18 

•define  UG  19 

•define  RG  20 

•define  XHITSI2E  21 

•define  XHITNUfl  22 

•define  RCUESI2E  23 

•define  RCUENUH  24 

•define  SELECT  25 

•define  RECORC  26 

•define  ACCEPT  27 

/*  These  constants  are  for  model  entries  only.  There  ore  no  */ 

/•  correspond ing  entries  in  search_liat  V 

•define  ENOJLQQP  51 

•define  EN0_IF  52 

•define  END_CRSE  53 

•define  COUNTERSET  54 

•define  FORJ.OOP  55 

•define  UHILE.L00P  56 

/*  Defines  the  uarious  pertinent  classes  to  which  a  string  moy  belong  */ 

•define  UNKNOUN  0 
•define  SlflPLENUft  1 
•define  NATURALNUN  2 
•define  CONPLEXHUII  3 
•define  RANGENUfl  4 
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•define  UflRNflflE  5 


/•  These  constants  describe  the  status  of  the  processing  •/ 

•define  BLANK  0 

•define  LOST  -I 

•define  UNOEFINEO  -2 

•define  INFINITE  -3 

•define  OEFRULT  -4 

•define  EXEC  -5 

•define  NO.EXEC  -6 


/*  Oefine  the  minor  frame  time  here  */ 
•define  N I N0RFRRI1E  10000 


enu*  boolean  {NO  *  0,  VES  *  1); 


struct  msg_pair 

{ 

int  num_msg_queued; 
int  num_packets; 

b 


struct  uar_info 

{ 

char  name[100}; 
int  ualue; 

>; 

struct  uar_l i st_i nfo 

{ 

struct  oar_info  entry[100]; 
int  length; 
int  marker; 

>; 

struct  string 

{ 

char  name[IOO]; 

)i 

struct  I i st_info 

( 

struct  string  entry[l00]; 
int  marker; 


i  nt  1 

>; 

length; 

struct 

match_info 

{ 

char 

name! 100] ; 

char 

>; 

f i 1  enamel  100]; 

struct 

count er_l i st 

{ 

int  num_sent; 
int  num_read; 
int  num_queued; 
int  num_retr ieved; 
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int  nua_msg— queued; 
int  msg_ retr i eued; 
int  total _t i ■ e ; 

>; 

struct  task— parse_i nfo 

( 

char  name[100]; 
int  rate-group; 

struct  counter— list  counter-set; 

); 

struct  message-l imits 

{ 

int  xmit— size; 
int  xmit_num; 
int  rcue_size; 
int  rcue_ num; 

)> 

struct  task— spec— i nfo 

{ 

char  name[100]; 

int  uirtual_group; 

int  rate-group; 

struct  message- I imits  limits; 

in¬ 
struct  ug_info 
{ 

enum  boolean  present; 
int  ouerrun[20] ; 
int  num_tasks; 

struct  task_parse_info  task[20]; 
int  rg_total[5]; 
int  ouerhead[8]; 
struct  msg_pair  msg_tota I [5] ; 

); 


struct  range_info 

< 

char  descript  ion [ 100]; 
int  first; 
int  last; 
int  span; 

)i 


struct 

< 

enum 

f 1 ag_l i st 

boo  1 

eon 

task-found; 

enum 

bool 

can 

pkg_ found; 

enum 

bool 

can 

ctr_ act i ue ; 

enum 

bool 

can 

finished; 

enum 

bool 

can 

fatal -error; 

enum 

boo  i 

can 

enab 1 e.when; 

>; 


int  proc_depth; 


struct  comment-info 
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< 

int  baslc_loop_l i»it ; 
int  for_loop_l i»it; 
int  nhi le_loop_l i»it; 
int  *essage_size; 

); 

struct  sodel_entry_info 

{ 

int  type; 

Int  value; 
int  depth; 
int  pointer; 
int  flow; 

); 

struct  iiodel_info 

{ 

int  length; 

int  nun_counters; 

struct  model_entry_info  entrytlOO]; 
struct  caunter_list  counter_set [ 1 00] ; 

); 


struct  proc_info 

{ 

char  nametlOO]; 
char  f i lename[100]; 
enum  boolean  done; 
struct  *odel_info  skeleton; 

>; 

struct  proc_l ist_info 

( 

struct  proc_info  entry[100]; 
int  length; 
int  narker; 
int  pkg_*arker; 

>; 

struct  constant..!  i  st 

{ 

int  queue_coeff; 

int  queue-const; 

int  retrieve_coeff; 

int  retrieve_const; 

int  IH_coeff; 

int  IH_const; 

int  RG0_Bsg_coet f ; 

int  RGO_»sg_const ; 

int  RG0_tsk_coef f; 

int  RG0_tsk_const ; 

int  RGQ_ouera I l_const ; 

int  RGO_enpty_queue_const ; 

int  context_s«itch; 

int  local_F0IR; 

int  sys_F0IR; 

}; 
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START.C 


•include  "header. h“ 

/* - - - - - - - - - 

CALLNRHE:  START.C 
AUTHOR:  S.  Treadeell 
CREATED:  19  11AV  92 
UPDATED:  20  JUL  92 

This  Is  the  preliminary  processing  code.  It  opens  up  the  task  specification 
file  and  processes  the  contents.  All  required  system  configuration  info  is 
stored  in  tmo  output  files  “task_names . dat "  and  "list_of_tasks.dat"  and 
passed  on  to  future  stages  in  the  analysis. 

- - - - V 


maln() 

( 

struct  task_spec_i nfo  task[20];  /*  temporarily  stores  all  config  info  */ 
struct  list_infa  search_list; 
struct  list_info  this_line; 

FILE  •infile; 

int  i,c; 

int  signal  *  1; 

Int  num_tasks  «  0; 

/•  Establish  the  list  of  key  words  that  control  the  search  for  config  info  */ 
read_l i st (&search_l i st ) ; 

/•  Open  the  task  spec i f i cat i on  file  V 
infile  ■  fopen( "task_l i st .ado" , "r " ) ; 
if  (infile  NULL) 

( 

pr i nt f( “Cannot  open  task_l i st_i o_. ada  \n“); 
exit  (2); 

} 

/•  Search  the  file  line  by  line  and  extract  relevant  info  */ 
do 
( 

signal  -  get _ I  i ne (8.1  h i » _ I  ine,  infi  le); 

search (&search_l i st ,&th is_l i ne, task, Hnum_t asks) ; 

} 

while  (signal  !»  0); 
fclose( inf  I le); 

/*  Produce  the  output  files  to  be  used  by  the  DCL  seorch  and  the  remainder  */ 
/•  of  the  analysis  */ 

write_f i le(task, num_tasks)  ; 
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CALLNAtlE :  REAO_L  I  ST 
AUTHOR:  S.  Treadwell 
CREATED:  13  APR  92 
UPDATED:  15  JUN  92 

This  procedure  establishes  the  list  of  key  words  that  control  the  search 
for  conf igurat ion  information.  The  list  is  taken  from  “key_words.dat" 
and  is  stored  in  search_list.  Each  key  word  occupies  a  separate  line  in 
the  external  file. 

- - - - - v 


read_l i st (search_l i st ) 

struct  I » st _ info  *search_l i st ; 

{ 

FILE  *1 ist_f i le; 
int  signal  «  0; 
int  ualue  =  0; 
int  num  -  0; 

I i st _ f i I e  ■  fopen ( "key_words . dat " ,  ”r  “ ) ; 

i f  ( I ist_f i le  «»  NULL) 

{ 

pr i nt f ( "Cant  open  key_words , dot  for  input\n“); 
ex  it (2); 

> 

whi lefsignal  !«  EOF) 

signal  -  fscanf(  I  ist_f  i  le,  "Xs\n"  ,  search— I  ist->entry[num  +  +  ]  .name) ; 

search_l ist->length  =  num  -  I; 
fclose( I ist_f i le); 

) 
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CRLLNfltlE:  GET_LIHE 
AUTHOR:  S.  Treadwell 
CREATED:  22  APR  92 
UPDATED:  fO  JUH  92 

Uill  use  the  stream  of  characters  prouided  by  the  specified  file  to  assemble 
a  buffer  of  single  word  items  oil  of  which  belong  to  a  single  line  of  code. 
The  key  here  is  to  gather  words  until  a  carriage  return  is  found. 

Blank  lines  are  not  recorded  in  the  buffer.  Comment  lines  are  recorded  as 
a  single  word  denoted  as  ‘  — 1 ;  all  additional  words  on  a  comment  line  are 
ignored.  This  procedure  will  not  record  a  line  of  words  if  it  is  terminated 
by  a  EOF  character. 


V 


int  get_l ine(this_l ine, inf i le) 
struct  list_info  *this_l ine; 

FILE  *  inf i le; 

{ 

int  c,k; 
int  num  *  0; 
int  count  ■  0; 
int  comment  -  NO; 
int  signal  ■  1; 
char  temp[8Q]; 

wh i I e( i sspace(c  *  fget c( i nf i I e) ) ) ;  /*  bleed  off  white  space  */ 
do 
{ 

if  (c  **  EOF)  break; 
do 

temp[count++]  *  c;  /*  append  character  to  word  */ 
whi le( ! isspoce(c  =  fgetc( inf i le))); 
temp[count]  ■  ' \ 0 ' ; 

strcpyfth i s_I ine->entry[num] . name, temp) ;  /*  append  word  to  line  */ 
do 

if  (c  ■*  ’\n' )  breok; 
whi le( isspace(c  -  fgetc( inf i le) ) ); 

count  «  0; 

if  ((k  -  strcmp(temp, ” — "))  ■■  0)  comment  *  VES; 
if  (comment  *>■  NO)  ♦♦num; 

} 

while  (c  !■  ' \n‘); 

if  (c  ■*  EOF)  signal  ■  0; 

t h i s _ I ine->length  ■  num; 

this.l ine->marker  *  0; 

return(s i gna I ); 

) 
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/*— . - - - - - - - 

CAtlNRflE :  SEARCH 
AUTHOR:  S.  Treadwell 
CREATED:  II  APR  92 
UPDATED:  22  JUN  92 

Uill  do  the  primary  parsing  for  the  "start"  stage.  Once  a  line  of  code  is 
available  for  analysisj  'search'  will  inspect  it  for  a  given  list  of  ado 
constructs  and  system  calls  and  will  branch  to  other  parsing  ond  analysis 
functions  as  dictated  by  uihat  is  found. 

This  procedure  looks  for  call  names  and  ado  constructs  exactly  as  given  by 
the  user  in  auxiliary  files.  Uhen  searching  for  matches,  names  that  are 
similar  but  not  exactly  the  same  as  the  names  sought  will  not  be 
sufficient  to  warrant  a  match. 

. . . . . . V 


search(search_l ist,this_l i ne, task, num_tasks) 
struct  list_info  *search_l i st ; 
struct  list_info  *this_line; 
struct  task_spec_i nf o  task[]; 
int  *num_tasks; 

{ 

int  i , j , k ; 
int  size; 

for(j  =  0;  j  <  search_l ist->length;  ++j ) 
for( i  *  0;  i  <  th i s_l i ne-> I ength;  ++i) 

if((k=  strcmp(th i s_l i ne->entry[ i ]. name, search_l i st->entry[ j }. name) )  ==  0) 

{ 

th i s_l i ne->marker  *  i  ♦  2; 

sw i t  ch ( j  ) 

{ 

case  GTID:  /*  extract  the  task  name  */ 
extroct_name(th i s_l i ne, task, num_t asks); 
break; 

case  UG:  /*  extract  the  task's  virtual  group  assignment  */ 

t ask [*num_t asks] .virtual _group  =  strip(this_li ne- >ent  ry [ i +2] . name  ) ; 
break; 

case  RG:  /*  extract  the  task's  rate  group  designation  */ 

t ask [ *num_t asks] . rat e_graup  *  get_rg( t h is_l ine->entry[ i +2] . name ) ; 
break; 

case  XHITSIZE:  /*  extract  message  passing  limitations  */ 

t ask [*num^t asks] .limits.xmit_size  =  strip(this_line->entry[i+2]. name ) ; 
break ; 

case  XniTNUM: 

t ask [*num_t asks] .limits.xmit_num  =  st r i p(  thi s_l i ne->en try [ i *2 ] . name) ; 
break ; 

case  RCUESIZE: 

t ask [ *num_t asks ] . I i m i t  s . rcve_s ize  =  strip(this_line->entry[i+2]. nome ) ; 
break ; 

case  RCUENUfl: 

t ask [ *num_t asks ] . I i m i t  s . rcve_num  =  strip(this_line->entry[i+2]. name) ; 

*num_tasks  +x  I ; 

break; 

default :  break; 

) 

) 

) 
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CALLNflflE :  UR  I  TE_F  I  L£ 

AUTHOR:  S.  Tread.ell 
CREATED:  26  HflV  92 
UPDATED:  12  JUN  92 

This  procedure  is  called  at  the  end  of  the  "start"  stage.  It  mill  produce 
too  output  files  for  use  by  later  stages,  The  first  file  contains  names  of 
the  tasks  i np I emented  in  the  task  suite;  it  is  used  by  the  DCL  search  in 
finding  the  files  inhere  the  tasks  reside.  The  second  file  contains  all 
pertinent  info  about  the  task  suite,  and  it  is  used  by  the  "finish"  stage  in 
parsing  the  tasks  and  calculating  ouerrui.s. 


*/ 


»rite_f i I e(task, num_tasks) 
struct  t ask_spec_i nf o  task[]; 
int  nu«i_tasks; 

( 

int  i , j , k; 
int  repeat; 

FILE  *outf i le; 

outfile  «  fopen(  “  I  i  st_o  f_t  asks  .  dat " ,  "ui" ) ; 
if  (out  f i le  “  NULL) 

( 

pr i nt f ( "Cannot  open  I i st_of_t asks . dat \n“ ) ; 
ex i t (2) ; 

> 

for( i  *  0;  i  <  num_tasks;  **i) 

fprintf(outfi le,"Xs  Xd  Xd  Xd  Xd  Xd  Xd\n“, 

task[i].name,task[i].ui rtua l_group, t ask [ i ) . rat  e_group , 
task[  i  ] . limits. xmit_size,task[i]. limits. xm it _num, 
task[i]. limits. rcue_s ize,task[i]. limits. rcue_num) ; 
c I ose(out  file); 

outfile  *  fopen(  "  t  ask_names  .  dat  "  ,  "ui"  )  ; 

I f(outf i le  *=  NULL) 

( 

pr i nt f ( "Cannot  open  the  output  f  i  I e\n “ ) ; 
ex i t (2) ; 

) 

for(i  ■  0;  i  <  num_tasks;  ♦♦ i ) 

( 

repeat  *  NO; 

for( j  -  0;  j  <  i ;  **j ) 

if  ((k  *  st rcmp(t ask( i ]. name , t ask[ j ]. name ) )  ='  0) 
repeat  *  VES; 
if  (repeat  •«  NO) 

fprintf(outfile,"Xs\n",task[i].name); 

> 

fprintf(outfi le,"done\n"); 
fclose(outf i  le); 

> 
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/* - - - — 

CALLNAME:  EXTRACT.NAflE 
AUTHOR :  S.  Treadwell 
CREATED:  26  flAV  92 
UPDATEO:  09  JUN  92 


Used  to  extract  task  name  from  the  task  specification  file. 


V 


extract_na«e(thi s_l i ne, task, num_t asks) 
struct  Ilst—Info  *this_line; 
struct  task_spec_info  task[]; 
int  *num_tosks; 

< 

char  temp[10]; 
char  task_name[1Q] ; 
int  count  =  6; 
int  count2  *  0; 
int  nun; 

num  =  t  h i 3 _ I i ne- >marker ; 

st rcpy( t emp, th i s_l i ne->ent  ry [ num] . name) ; 

/*  eliminate  the  prefix  "gtids.”  from  the  task  name  */ 
while  (temp[count  ]  !=  ',') 

task_name[count2++]  =  t emp[ count ♦  +  ]  ; 
task_nametcount2]  =  ' \0 1 ; 

/*  Adhere  to  the  naming  contention  for  task  names  */ 
strcat (task_name, "_t " ) ; 

strcpy ( task [ *num_t asks ] . name , t ask_name) ; 


) 
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/*— . . . . 

CALLNAI1E :  STRIP 
RUTHOR:  S.  Treadwell 
CREATED:  26  DAY  92 
UPDATED:  12  JUH  92 

Used  to  take  the  comma  off  the  end  of  a  number  and  convert  it  from  a  string 
to  an  integer. 

- - - ♦/ 


int  3trip(argument) 
char  argu*ent[]; 

{ 

int  count  *  0; 
int  value  *  0; 
char  temp[20]; 

/*  strip  the  comma  off  the  end  */ 
whi le(argument [count  ]  !*  ',') 

{ 

templcount]  *  argument [count ] ; 
count++; 

} 

temp[count ]  »  ' NO ' ; 

/*  convert  the  string  to  an  integer  value  */ 
value  ■  strtol (temp, (chor  **)NULL, 10); 
return(value); 


/* - - - . - . 

CALLMAHE:  GET_RG 
AUTHOR:  S.  Treadwell 
CREATED:  26  MAY  92 
UPDATED:  12  JUN  92 

This  extracts  the  rate  group  number  for  a  task  from  the  task  spec  file. 
- - - - - - . -V 


int  get_rg(argument ) 
char  argument!]; 

( 

char  r g [ 10]; 

/*  grab  the  rg  *  directly  and  convert  it  to  an  integer  */ 
rg[0]  *  argument [9] ; 
rg! 1 ]  -  'NO'; 

return(st rto I (rg, (char  **)NULl , 10)); 

} 
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DCL  Source  Code 


ANALYZE.COM 

This  program  orchestrates  the  entire  analysis  process  from  start  to  finish. 

Srun  start 
$®f I nd 
$run  finish 
Sexi  t 


FIND.COM 

This  program  finds  the  files  that  hold  the  application  task  source  code  and  produces 
“filenames.dat”  as  output. 

$task  ■  “task" 

Sbady  *  "body" 

Sis  -  “is" 

Sisearch  /windowO  /output =t emp . dot  /motch'and- 
S !  [ ft pp . af  ta .  source  .  cits  I  i  b  .  .  .]. ado - 
$!  ’task  Vbody  V  is‘ 

Ssearch  /mindos-O  /output=temp . dot  /match'and- 
[t readme  I I .af ta. . .  ]  .  adJ- 
‘task’ , 'body', ' is’ 

$open/append  out  file  temp. dot 
Smrite  out  file  "done" 

Sc I ose  out  file 
$type  temp. dot 

Sopen/mrite  out  file  filenames.dat 
$open/read  taskfile  task_names.dat 
Sbigloop: 

(read  taskfile  taskname 

$if  taskname  .eqs.  "done"  then  goto  finished 
Smrite  outfile  tasknome 
Sopen/read  infile  temp.dat 
$  I oop : 

$read  infile  filename 

$if  filename  .eqs.  "done"  then  goto  done 
Ssearch  'filename'  'taskname' 

$match  »  Jseuerity  .eq.  I 

$if  match  then  mrite  outfile  filename 

Sgoto  loop 

(done : 

Sc  lose  inf i le 
Sgoto  bigloop 
$f ini  shed: 

Sc  I ose  out  file 
Sc  I ose  t  ask  file 
St ype  f i I enames . dat 
S ! purge 
Sexit 
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•include  “header. h" 

/*  Thia  is  the  controlling  "mo in"  for  finish.exe  */ 

moin() 

{ 

uoid  watch— up(); 

uoid  process-l iet(); 

uoid  check— ouerrun( ) ; 

uoid  wr ite_f i le(); 

struct  watch-info  task[10]; 

struct  ug_info  ug[40]; 

struct  constant-list  delay-data; 

int  i ,n; 

int  nua_ tasks; 

FILE  *error_f i le; 

error-file  *  fopenf “errors  . dot  ", "w" ) ; 
i f (error_f i I e  NULL) 

{ 

pr i nt f ( “Cannot  open  errors.dat  for  output\n“); 
ex i t (2) ; 

} 

match— upftaskj&num-tasks.error-f i le) ; 

/*  The  foil oui  i ng  info  tells  the  user  which  uersion  of  the  task  suite  is  */ 
/*  being  analyzed.  Note  it's  recorded  in  the  error  log  rather  than  the  */ 
/*  resu I ts  f i I e .  * / 

fprintf(error_f i le, “The  matching  between  tasks  and  filenames  is...\n“); 
for  (i  ■  0;  i  <  num_ tasks;  ♦♦i) 

fpr i nt  f (error— f i I e , "Id  Xs  Xs\n", i, task [ i ] . name, task[i], filename); 
process— I i st (ug, t ask , num_t asks ,&de I ay_dat a, error_f i le); 
check_ouerrun(ug,8ide I ay_data, error_f i le) ; 

■r i te_ f i I e(ug) ; 
fc I ose(error_f i le); 

> 


123 


Appendix  D 


» 


CRLLNRHE :  f1RTCH_UP 

AUTHOR :  S,  Treadwell  . 

CREATED:  27  flflV  92  9 

UPDATED:  25  JUN  92 

Takes  the  output  file  from  the  DCL  task  body  search  and  performs  a  matchup 
between  task  names  and  the  files  in  which  they  reside.  If  the  task  uias  not 
found,  it  is  watched  with  a  “none."  If  the  task  name  uios  found  in  multiple 

files,  the  user  is  giuen  notice  and  the  choice  of  uihich  file  he  wants  to  ) 

haue  processed  for  that  task.  This  giues  the  user  the  choice  of  which 
uersion  of  a  task  he  wants  to  haue  analyzed  since  it  is  assumed  that  seueral 
versions  of  the  same  task  may  be  present  in  the  target  directory. 

- - »/ 


void  mat ch_up( task , num_t asks , error_f i I e ) 
struct  match_info  task[]; 
int  *num_tasks; 

F I LE  *error_f i I e; 

( 

struct  string  f  i  I  e[ 1 0] ; 

int  i  *  0; 

int  j  -  0: 

int  num  *  0; 

int  choice  *  0; 

int  signal  *  0; 

int  k , n, c ; 

char  dunmy[80]; 

FILE  ‘infile; 

infile  ■  f open( " f i I enames  .  dot “ ,  "r  " ) ;  /*  File  produced  by  the  DCL  search  */ 
if  ( i n f i I e  ■“  NULL ) 

{ 

fpr i nt f ( error_f i I e , “Cannot  open  filenames  dat  for  input\n“); 
ex  i  t (2) ; 

> 

/*  Data  format:  task  name  followed  by  corresponding  filename(s)  with  each  */ 
/*  name  listed  on  a  separate  line.  The  first  ta3k  name  is  grabbed  and  */ 
/*  converted  to  typical  string  format.  */ 

fsconf( infi le, "Js\n"  ,task[  i  ]  .name) ;  strcat<task[  i  .name,  “\0" )  ; 

/*  Now,  corresponding  filename(s)  and  additional  task  names  ore  grabbed  */ 
/*  from  the  file  and  converted  to  string  format.  Whenever  a  new  task  name  */ 
/*  is  found,  the  filename(s)  for  the  previous  task  get(s)  processed.  Note  */ 
/*  that  0,1,  or  multiple  filenames  (up  to  10)  can  be  hondled  for  eoch  task  */ 
do 


» 


> 


» 


> 


» 


signal  *  f scan f (  i  n f  i  I e ," Xs\n" , dummy ) ;  st root ( dummy , “\0" ) ;  /*  grab  name  */ 

num  «  st r I en(dummy ) ;  ® 

if((((c  *  dummy[num- I  ] )  --  '  *.  '  )  &&  ((c  *  dummy  [  num- 2  ]  )  --  '_'))  II 
(signal  ■*  EOF))  /*  Is  it  a  task  name?  or  the  end  of  the  file?  */ 

( 

switch(j)  /*  Process  filename(s)  for  last  tosk  name  */ 

( 

case  0:  st rcpy ( t ask [ i - I ] . f i I ename , “none” ) ;  break;  ) 

case  I:  st rcpy ( t osk [ i - I ] , f i I ename , f i ! e [ 0] . nome  ) ,  break; 

default:  /*  Let  the  user  choose  which  uersion  of  the  tast  •  ,-e  * 
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pr i nt f ( “flu  1 1 i p I e  files  found  for  the  tosk  colled  Xs\n“ ,  task  [  i ]  name ) ; 
for  (n  *  0 ;  n  <  j ;  ++n) 

printf(“%d  :  Xs  \n" ,  n,  f  i  I  e[n] .  name) ; 
prlntf("Vour  Choice:  ");  scanf ( “Xd“ ,icho i ce) ; 

I  f (cho ice  <  j ) 

strcpy(task[ i  —  1 3 . f i I ename , f i lefchoice]  name); 

) 

if  (signal  I”  EOF) 

< 

st rcpy(tosk[ i ]. name, dummy ) ;  /*  If  it  mas  a  task  name,  store  it  */ 

♦♦i;  j*0; 

} 

) 

else 

strcpy( f i I etj ♦+]. name, dummy ) ;  /*  If  not,  store  it  as  a  filename  */ 

) 

•hi le(signol  !=  EOF) ; 

*num_tasks  *  i; 

/*  Procedure  ends  with  an  array  of  paired  names  stored  in  task[].  Each  */ 
/*  task  name  has  a  single  filename  associated  with  it  (or  "none”)  and  */ 
/*  num_tasks  reueals  how  many  tasks  are  included  in  the  analysis  */ 

) 
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> 


/* - 

CALLNAHE :  PROCESS_LIST 
AUTHOR:  S.  Treadwel  I 
CREATED:  09  JUN  92 
UPDATED:  M  OCT  92 

Takes  the  output  file  from  3tart.exe  and  gleans  from  It  all  the  necessary 
information  about  the  task  suite  that  is  contained  in  the  task  specification 
file.  The  information  is  then  grouped  and  stored  according  to  the  ugs  in 
ohich  the  tasks  reside.  Note  that  task  parsing  and  analysis  is  initiated 
here,  and  the  results  stored  in  ug[]  are  later  submitted  to  check_ouerrun 
for  an  integrated  hardware  and  software  conf i gurat i on  analysis. 


uoid  process_l i st (ug , t ask , num_t asks, de I ay_dat a , error_f i le) 

struct  ug_info  ugt];  ) 

struct  match_info  t ask [  ] ; 
int  num_tasks; 

struct  constant-! i st  *delay_data; 

F I LE  *error_f i I e ; 

( 

uo i d  read_l i st ( ) ; 

struct  counter-list  t ask_parse( ) ;  ® 

struct  message— I i m i t s  messages; 

struct  list-info  search-list; 

int  i , j , k; 

int  nun; 

int  num_loaded; 

int  marker;  ) 

int  ugnum; 

int  rgnum; 

int  si gna I ; 

char  dummy[80]; 

char  task_name[80] ; 

FILE  *inf  i  le; 

» 

infile  *  f open< "  I  i st_of_t ask3 . dat ” , "r “ ) ;  /*  File  produced  by  start.exe  */ 
i f< inf i le  ==  HULL) 

( 

fpr i nt f (error_f i I e , "Cannot  open  I i st-of-tasks , dat  for  input\n"); 
ex i t (2) ; 

>  » 

/*  Establish  the  array  of  key  words  that  will  be  used  in  the  software  */ 

/*  modeling  and  onalysis  phase.  Also  process  the  system  specific  delay  */ 

/*  ualues  and  store  them  in  delay-data.  */ 

search_l i st . I ength  =  0; 

read- 1 istf&search-l ist.del oy_dat  o) ; 

» 

whi  led  ) 

( 

/*  Grab  information  relating  to  a  single  instantiation  of  o  single  task  */ 

/*  Each  task  instantiation  is  giuen  a  single  line  in  the  input  file  */ 

/*  The  format  should  be  readily  apparent  from  the  fscanf  statement  below  */ 
signal  »  f  3canf  (  i  n  f  i  I  e  ,  "  Xs  Xd  Xd  Xd  Xd  Xd  Xd\n"  ,  t  ask_name  ,8.ugnum  ,8.rgnum  , 
imessages.xmit-size.&messages.xmi t_ num , 

& messages. rc ue_s ize,&messages. rcue_num ) ; 
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if  (signal  «»  EOF)  break;  /*  End  of  file  terminates  the  procedure  */ 

/*  Find  the  filename  for  the  task  that  is  to  be  analyzed  and  mark  it  */ 
for(j  “  0;  j  <  num_tasks;  +*j ) 

if((k  *  st rcmp(task_name, task[ j ] . name) )  - -  0)  marker  =  j; 

/*  Update  appropriate  ug  record  according  to  the  task  instantiation  */ 

/*  Note  that  each  task  instantiation  is  processed  indiuidually  so  that  */ 

/*  different  message  passing  limitations  can  be  analyzed  for  a  single  */ 

/*  task.  */ 

num  -  ugtugnum] .nun_tasks; 

ugtugnum] . present  *  VES;  /*  Ves,  this  ug*  exists  in  this  configuration  */ 
ugfugnu*] .num_tasks  ♦*  1; 

strcpy(ug[ugnum] .task [num] . name, task_name) ; 
ug[ ugnum] . t ask [ num ] . r a t e_group  *  rgnum; 

/*  Now  kick  off  the  analysis  of  the  specified  task  with  the  call  to  */ 

/*  task_parse.  The  analysis  culminates  in  the  establishment  of  a  single  V 
/*  counter_set  that  will  represent  the  specified  task  instantiation  */ 

/*  during  the  integrated  hardware  and  software  analysis  in  check_ouerrun  */ 
fpr intf(error_f i le,  fSOFTlIflRE  flNALVSIS  FOR  Xs\n\n“ , t osk[marker ] . name  ) ; 
ug [ ugnum] . task[ num] . count er_set  = 

t  ask_parse(&search_l i st , de I ay_dat  a, tosk [marker] . name , 
task [marker] . f i lename , messages, err or_f i I e) ; 

} 

fclose( inf i le); 

/*  This  procedure  completes  with  vg[  ]  holding  all  config  information  as 
l*  well  as  all  worst  case  execution  delay  analysis  results  for  each 
/*  instantiation  of  euery  task  in  the  suite. 

) 


*/ 

V 

*/ 
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» 


CALLNAtlE:  TASK-PARSE 

AUTHOR :  S.  Treadwell  t 

CREATED:  10  AUG  92 
UPDATED:  11  OCT  92 

This  procedure  has  responsibility  for  modeling  and  analyzing  a  single  task 
to  find  a  parameter i zed  expression  for  the  worst  case  execution  path  through 
the  task  for  a  single  execution  cycle.  The  parameter i zat i on  is  returned  to 

the  parent  procedure.  ► 

- - - */ 


struct  count er_l i st  task_parse(search_l i  st , de I ay_dat a, t ask_name , f i I ename , 

messages , error_f i I e) 
struct  list_info  *search_l i st ; 
struct  constant_l i st  *delay_data; 
char  task_name[ ] ; 
char  f i I ena«e[ ] ; 
struct  message.! i • i t s  messages; 

FILE  *error_f i le; 

( 

void  f i nd_packages( ) ; 

void  parseO;  ) 

void  pr i nt _procedures( ) ; 

struct  counter-list  f i nd_worst_path( ) ; 

struct  I i s t _ info  pkg _ list; 

struct  model_info  skeleton; 
struct  counter-list  f i na I -count er ; 
struct  proc_ I i 3 1 _ i nfo  procedures; 

struct  counter-list  counter-set;  ^ 

struct  flag-list  flags; 
char  pkg_f i I ename[80] ; 
char  pkg_name[80] ; 
i nt  i , k ; 

/*  Set  a  flag  in  the  error  log  to  help  establish  the  chronology  of  the  */  I 

/*  analysis  and  any  errors. 

fpr i nt f (error-f i I e, “Uork i ng  an  Xs\n" , task-name) ; 

/*  Initialize  the  worst  case  parameterization  for  the  task  */ 
f i na I _ count er . num_ queued  *  G; 
f i na I _ count er . num_ ret r i eved  *  0; 

f i na I— count er . num_sent  =0;  ► 

f i na I— counter . num_read  =  0; 

if  ( ( k  *  strcmpf f  i  I  ename , "none" ) )  =  =  0) 

{ 

fpr  i  nt  f  <  error— f  i  I  e ,  "  No  file  was  found  for  task  J!s\n" ,  t  ask_name  ) , 
goto  doneparsing; 

)  * 

/*  Prepare  for  bottom-up  modeling  */ 
pkg_ I i st . I ength  »  0; 

procedures . I engt h  *  0;  procedures . marker  =  0;  procedures , pkg_ morker  =  0; 
ske I et on . I engt h  =  0;  ske I et on , num_count ers  -  0; 

» 

/*  Establish  the  task's  procedure/package  hierarchy  */ 
f  i  nd_packages(  fi  lename,8,pkg_l  ist,error_fi  le); 
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/*  Starting  at  the  bottom  of  the  package  list,  each  package  is  processed  V 

/*  individually  to  collect  procedure  models  in  preparation  for  modeling  */  | 

/*  the  actual  task  body.  V 

for  <1  *  pkg_l  i  st  .  I  ength  —  1  ;  i  >=■  0;  — i) 

( 

strcpy(pkg_f i I ename , pkg_list.entry[i].na«e); 

st rcat (pkg_f i I ename, “ . ada" ) ;  /*  Filename  is  deriued  from  package  name  */ 
parse (search— I i st , de I ay_dat a , pkg_f i lename,pkg_l ist .entry[ i ]  name, t ask_name , 

messages, iprocedures ,&ske I eton, tf I ags, error_f i le);  * 

> 

/*  Now  parse  model  the  task  body  since  all  supporting  procedures  */ 

/*  haue  already  been  examined  */ 

strcpy(pkg_name, “none" ) ; 

parse (search- 1 i st , de I ay_data, f i I ename , pkg_name, t  a3k_name .messages,  I 

8,procedures,&ske  leton.&flags,  error_f  i  I  e) ; 

/*  Record  info  in  the  error  log  to  help  with  any  debugging  needed  V 
pr i nt_ procedures (fcprocedu res, error_f i I e) ; 

/*  Norn  analyze  the  resulting  task  model  to  find  the  worst  case  exec  path  */ 

/*  assuming  that  the  task  body  was  found  in  the  specified  filename  */  ► 

i ((flags. task— found) 

( 

f  i  na  l_count  er  «  f  i  nd_worst-pat  h(&ske  I  et  on,  de  I  ay_dat  a,  error_f  i  le); 

/*  Record  results  in  output  file  */ 

fpr i nt f (error_f i I e , " The  worst  path  i3  characterized  by...\n“); 
fpr i nt f(error_f i I e, "Queued :  X3d  Retrieved:  X3d  Sent:  X3d  Read:  *3d  \n", 
final— counter. num_ queued , f i na i_ count er . num_ ret  r i eued , 
final -counter. num_sent , f i na I -count er . num_read) ; 

) 

e  I  se 

fpr i nt f ( error-f i  I e , ” The  task  Xs  was  not  found  in  Xs\n" , t ask-name , f i  I ename ) ; 

doneparsing:  ret  urn ( f i na I -count er ) ;  ) 

/*  f i na I _ count er  holds  the  worst  case  path  paramet er i zat i on  and  is  stored  */ 

/*  by  the  parent  procedure  (process— 1 i st )  in  the  appropriate  ug  record  as  */ 

/*  the  definitive  representation  of  the  given  task  instantiation  */ 


* 


» 


» 
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/*— - - - - - - 

CALLNAflE :  F I  ND_PACKAGES 

AUTHOR:  S.  Treadwell  t 

CREATED:  12  JUL  92 
UPDATED:  15  OCT  92 

This  procedure  builds  the  structural  hierarchy  for  a  gioen  task  by  examining 
its  context  clause  for  package  names  upon  which  the  task  depends.  It  also 
examines  context  clauses  for  all  supporting  packages  to  find  packages  upon 

which  they  depend.  The  result  is  a  one-dimensional  array  of  package  nones  ► 

with  the  most  fundamental  packages  at  the  bottom  of  the  list  --  in  other 
words,  the  packages  toward  the  top  of  the  list  depend  upon  the  ones  at  the 
bottom  of  the  list. 

- */ 


uoid  f i nd_packages( f i I ename , pkg _ I i st ,error_f i I e)  ^ 

char  f i I ename[ ] ; 

struct  I i st _ info  *pkg_list; 

F  HE  *error_f  i  le; 

{ 

uoid  update_pkg_l i st ( ) ; 
int  i , j ; 

char  pkg_f i I ename[ 80] ;  ) 

/*  Look  at  the  context  clause  in  the  package  containing  the  task  body  */ 
updat e_pkg_l ist(fi lename,pkg_l ist, error_f i I e) ; 

/*  Look  at  the  context  clause  in  all  packages  contained  in  package  list  */ 

/*  Any  new  packages  found  are  appended  to  the  list,  and  the  search  V 

/*  continues  in  a  recursiue  mcnner  until  reaching  the  end  of  the  package  */  ® 

/*  I  ist  .  V 

for(i  -  0;  i  <  pkg_l i st - > I engt h ;  +  ♦  i  ) 

( 

Strcpy(pkg_filename,pkg_list->entry[i].nome); 
strcat(pkg_fi lename,".ada"); 

updat  e_pkg_l i3t(pkg_filename,pkg_list,error_file);  I 

) 

/*  Record  results  in  error  file  purely  for  debugging  purposes  */ 
f pr i nt f (error_f i I e, “ The  packages  found  are..,"); 
i f (pkg_ I i st - > I engt h  ~~  0)  fpr i nt f (error_f i le, "none" ) ; 
fprintf(error_fi I e, "\n" ) ; 

for( i  -  0;  i  <  pkg _ I  i st - >  I  engt h ;  ♦♦i)  ► 

fpr i nt  f (error_f i le,"Xs\n",pkg_l ist->entry[i].name); 


> 


» 


> 
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/* - - - - - 

CALLNRFIE :  UPOATE-PKG-L  I  ST 
AUTHOR:  S.  Treadwell 
CREATED:  15  JUL  92 
UPOATED:  18  NOU  92 

This  procedure  examines  the  context  clause  of  a  giuen  package  in  order  to 
find  names  of  packages  upon  which  the  giuen  package  depends.  This  is  a 
method  of  exploring  the  subprogram  hierarchy  for  a  giuen  task,  and  ail  new 
package  names  found  in  the  context  clause  are  appended  to  the  package  list 
to  be  later  examined  by  this  procedure. 


uo i d  update_pkg_l i st ( f i I ename, pkg_l i st , error_f i I e) 
char  filename!]; 

struct  I i st _ info  ♦pkg _ list; 

FILE  *error_ f i le; 

( 

uoid  ui i  t h _ found ( ) ; 

struct  I  I st _ info  t h i s _ line; 

struct  list_info  comment_l ine; 
struct  comment_info  info-buffer; 
int  i ,  j i kj 

int  signal  =  1;  /*  Serues  to  signal  the  end  of  the  file  */ 

FILE  * i nf i le; 

infile  =  fopen( f i I ename,  “r" ) ; 

i f < i nf i I e  ! «  NULL) 
while  (signal  ! -  0) 

{ 

/*  Search  the  file  looking  for  a  program  statement  of  the  form  . . .  */ 

/*  “with  [PKG— NRflE];"  Uhen  such  a  statement  is  found,  the  packoge  */ 

/*  name  is  extracted  and  checked  against  the  package  list  to  */ 

/*  determine  if  it  should  be  appended  to  the  current  list  */ 

s i gna I =get_l i ne(&t  h i s_l i ne,&comment_l i ne , & i nfo_bu ffer, infi le,error_fi  le) 
if((k  =  3t rcmp(t h i s_l i ne . entry [0] . name , "w i t h” ) )  ==  G) 

( 

th i s_l i ne . marker  =  1 ; 

with_found(&this_l ine,pkg_i ist, infi le); 

} 

> 

fc I ase( infile); 

) 
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/* . . . . . . 

CALLNAflE :  PARSE 
AUTHOR :  S.  Treadwell 
CREATED:  10  JUL  92 
UPDATED:  18  NOU  92 

A  generic  code  processing  procedure  that  accepts  code  from  all  types  of 
program  units  —  packages,  subprograms,  and  tasks.  For  subprograms,  it 
constructs  code  models  and  odds  the  model  info  to  the  procedures  data 
structure.  Uhen  dealing  with  a  task  body,  the  task  model  is  deueloped  and 
returned  to  task_parse  in  the  skeleton  data  structure. 
- - - ./ 

uo i d  parse(search_l i st , de I ay_dat a, f i lename, pkg_name , t ask_name, messages , 
procedures, ske I et on, flags, error_f i I e) 
struct  list_info  *search_l i st ; 
struct  constant—l i st  *deiay_data; 
char  f i I enamet ] ; 

char  pkg_name[];  /*  Passed  as  “none"  when  parsing  the  task  body  file  */ 

char  task_name[]; 

struct  message_l i m i t s  messages; 

struct  proc_l i st_i nfo  ‘procedures;  /*  Holds  all  subprogram  models  */ 
struct  model_info  ‘skeleton;  /*  Always  holds  the  current  model  */ 

struct  f I ag _ f i st  ‘flags;  /*  Prooides  important  stav  <  information  */ 

FILE  *error_f i le; 

( 

i nt  get_l i ne( ) ; 
ooid  searchO; 

struct  I i 3t _ info  t h i a _ line;  /*  Holds  the  current  program  statement  */ 

struct  I i st _ i nfo  comment.! i ne ;  /*  Used  to  grab  uital  programmer  input  */ 

struct  list. info  end.list;  /*  Needed  for  status  info  */ 

struct  comment.info  info.buffer;  /*  Holds  current  summary  of  prog,  input  */ 
int  signal  =  1;  /*  Signals  when  the  end  of  the  giuen  file  is  reached  */ 
int  i,k; 

FILE  ‘infile;  /*  Ada  source  file  that  is  currently  being  parsed  */ 

FILE  ‘outfile;  /*  Error  log  */ 

/*  Set-up  */ 
end_l i st . I ength  =  0 ; 
comment.l i ne . I engt h  =  0; 
th i s_l i ne . I ength  =  0 ; 

f I ags->ctr_act i ue  =  NO; 
f lags->pkg_found  =  NO; 
f I ags->t ask_f ound  «  NO; 
f I ags->f i n i shed  =  NO; 
f I ags-> fat  a l.error  -  NO; 
f I ags->enab I e.when  =  NO; 
f I ags->proc_depth  =  0; 

i n fo_buf fer . bas i c_l oop_l i m i t  =  INFINITE; 
i nfo.buf fer . for_l oop_l i m i t  =  UNDEFINED; 
i n fo.buf fer , wh i I e_l oop_l i m i t  =  UNDEFINED; 
i n fo_buf fer . message.s i ze  =  DEFAULT; 

/*  Note  that  it  is  assumed  that  all  packages  and  files  upon  which  o  task  */ 
/*  depends  are  included  in  the  same  directory  as  the  task  body  file  * 

infile  •  f open ( f i  I  ename , "  r " )  ; 
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ifOnfi  le  «■  NULL) 

{ 

fpr  i  nt  f  (error_f  i  I  e ,  “F  i  I  e  JCs  could  not  be  f ound\n” , f i I ename ) ; 
goto  done_pars i ng; 

) 

/*  Help  specify  the  chronology  of  the  error  log  by  listing  the  file  that  */ 
/*  is  currently  being  processed  */ 

if((k  *  strcsp(pkg_name, "none" ) )  ”*  0)  /*  Is  this  the  actual  task  file?  */ 
fpr int f (error_f I le, "Now  processing  task  Xs\n“ , task_nome) ; 

e  I  se 

fprint f(error_f i le, “ Norn  processing  package  Xs\n" , pkg_name) ; 

do 

{ 

/*  Grab  program  statements  one  by  one  ond  examine  them  on  an  individual  */ 
/*  and  chronological  basis.  V 

s  i  gnal  ■=  get_l  i  rte  (& t  h  i  s _ I  ine,&comment_l  i  ne,&  i  nf  o  _buf  f  er ,  infi  le,error_fi  le); 

search(search_l ist , del ay_data, ske I et on,&th i s_l i ne, f I ags ,&end_l i st , 

& i nf o_buf  fer , pkg_name, task_name , messages, procedures , f i I ename , 
error_f i I e) ; 

} 

uih i I e( (s i gna I  !=  0)&&( f I ags->f i n i shed  ==  N0)&&( f I ags- >f at  a l_error  ==  NO)); 
done_pars i ng ; j 

/*  The  critical  data  structures  updated  in  this  procedure  are  skeleton  and  */ 
/*  procedures  because  these  hold  the  groining  collection  of  subprogram  and  */ 
/*  task  models.  Uhen  task_parse  calls  parse  for  the  final  time  to  examine  */ 
/*  the  actual  task  body,  "skeleton"  is  left  with  the  final  task  model  and  */ 
/*  is  later  passed  on  to  the  model  analysis  procedures  */ 

) 
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/* - - - - 

CALLNAtlE :  CHECK-OUERRUN 
AUTHOR:  S.  Treadwell 
CREATEO:  09  JUN  92 
UPDATED:  20  OCT  92 

At  this  point  in  the  analysis,  a  worst  case  path  parameter i zat i on  has  been 
established  for  each  task  instant i at i on  in  the  suite.  These  path 
parameter i zat ions  haue  been  used  to  establish  the  critical  data  values  for 
each  ug,  and  it  is  the  ug  records  that  are  used  for  the  performance  failure 
predictions  or  "overrun  checks."  This  procedure  performs  the  overrun  check 
for  all  40  vgs  (or  at  least  the  ones  that  exist)  and  leaves  the  overrun 

info  in  an  array  that  is  part  of  the  vg  record.  The  u» n i t e file  procedure 

is  responsible  for  later  extracting  and  ciphering  the  overrun  info. 
- - - */ 


void  check_overrun( vg, de I  ay-data, error_f i le) 

struct  vg_info  vg[]; 

struct  constant-.!  i st  *delay_data; 

F I LE  *error_f lie; 

{ 

int  ca I cul ote_ t i me( ) ; 

int  vg-num; 

int  '•ate-group; 

int  rg_total; 

int  num_tasks[5] ; 

int  num_t asks— comp  I et ed[9] ; 

int  num_msg_ queued[8] ; 

int  num_packets_queued(8] j 

int  num_rate_ groups_due[8] ; 

int  overheod[8]; 

int  i,j; 

/*  For  each  passible  virtual  group  in  the  system...  */ 
for(vg_num  =  0;  vg_num  <  40;  ♦♦vg-num) 

{ 

if  (vg[vg_num] . present  ==  VES)  /*  If  the  vg  has  any  tasks  resident  in  it  * 
{  ' 

for(i  =  0;  i  <  5;  ♦♦ i )  /*  Initialize  intermediate  tally  variables  *  / 

( 

num_tasks[ i ]  =0; 

vg[ vg-num] .rg_total [ i ]  =  0; 

vg[ vg_num] . msg_ t ot a  I [ i ] . num_msg_queued  =  0; 

vg[vg_ num] .msg-total 1 i ] .num_packet3  =  0; 

} 

for( i  =  0;  i  <  vg[ vg— num] .num_tasks;  ++i)  /*  For  each  task  in  the  vg  * 

< 

rate— group  =  vg[vg_ num] . task[ i ] .rate— group;  /*  Simplify  notation  */ 
♦♦num_ t asks(rat e_group ] ;  /*  Establish  how  many  tasks  ore  in  each  rg  */ 

/*  For  each  rg,  establish  a  tally  of  delay  time  for  all  tosks  */ 
ug[ug_ num ] . rg_ t  ot  a  I [ rot  e— group ]  +  = 

vg[ vg-num] , t ask[ i J . counter-set . t  ot  a l_t i me ; 

/*  For  each  rg,  establish  a  tally  of  queued  packets  for  oil  tasks  *./ 
vg[ vg_num] . msg_ t  ot  a  I [rat  e_group] , num_packet  s  ♦  = 
vg[vg_num] .taskt i ] .counter-set . num_queued ; 

/*  For  each  rg,  establish  a  tally  of  queued  messages  for  all  tasks  */ 
vg[vg_num] .msg_ total [rate_group] . num-msg_queued  ♦= 
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vg[vg_num] . tosk[ i ] .counter_set . num_msg_queued; 

} 

for( i  3  0;  i  <8;  ++  i ) 
overhead! i  ]  3  0; 

/*  For  each  minor  frame,  establish  hoe  many  tasks  should  haue  */ 

/*  completed  execution  cycles  during  the  previous  minor  frame  */ 

num_t asks_comp leted[0]  »  vg[vg_num] .num.tasks; 
nu#_t asks_comp let ed[ I ]  3  num_tasks[4] ; 
num_tasks_completed[2]  =  num_tasks[4]  ♦  num_tasks[3] ; 
num_tasks_completed[3]  -  nu*_tasks[4]; 

num_tasks_completed[4]  3  num_tasks[4]  +  num_tasks[3]  +  num_tasks[2] ; 
num_tasks_completed[5]  =  num_tasks[4] ; 
num_tasks_completed[6]  =  num_tasks[1]  +  num_tasks[3] ; 
num_tasks_completed[7]  =  num_tasks[4] ; 
num_tosks_completed[8]  -  num_tasks_compl etedtO] ; 

/*  For  each  minor  frame,  establish  hoe  many  messages  are  queued  by  */ 
/*  tasks  that  should  have  completed  cycles  during  the  previous  frame  */ 
num_msg_queued[0]  =  vg[vg_num] . msg_total [4] . num_msg_queued  + 

vg[vg_num] ,msg_total [3] . num_msg_queued  + 
ug[vg_num] ,msg_total [2] . num_msg_queued  * 
vg[vg_num] ,msg_total [ I ] . num_msg_queued ; 
num_msg_queued[ I ]  *  vg[ vg_num] . msg_t ot a  I [4 ] . num_msg_queued ; 
num_msg_queued[2]  ■  vg[vg_num] .msg_total [4] .num_msg_queued  + 

vg[vg_num] ,msg_total [3] . num_msg_queued ; 
num_msg_queued[3]  3  num_msg_queued[ 1 ] ; 

num_msg_queued[4]  =  vg[vg_num] ,msg_total [4] . num_msg_queued  + 

vg[vg_num] .msg_total [3] . num_msg_queued  + 
vg[ug_num] .msg_total [2] . num_msg_queued ; 
num_msg_queued[S]  =  num_msg_queued[ 1 ] ; 
num_msg_queued[6]  3  num_msg_queued[2] ; 
num_msg_queued[7]  3  num_msg_queued[ I ] ; 

'*  For  each  minor  frame,  establish  hoe  many  packets  are  queued  by  */ 
/*  tasks  that  should  have  completed  cycles  during  the  previous  frame  */ 
num_packets_queued[0]  3  vg[ug_num] . msg_total [4] .num_packets  ♦ 

vg[vg_num] .msg_total [3] ,num_packets  + 
vg[vg_num] .msg_total [2] ,num_packets  ♦ 
vg[ vg_num ] . msg_t ot a  I [ 1 ] . num_packet  s ; 
num_packets_queued[ I ]  3  vg[ug_num] . msg_tot a  I [4] . num_packet s ; 
num_packets_queued[2]  3  vg[ug_num] . msg_tot a  I [ 4 ] . num_packet s  * 

vg[vg_num] . msg_total [3] . num_packet s ; 
num_pocket s_queued[3]  3  num_packets_queued[ I ] ; 
num_packets_queued[4]  3  vg[ vg_num] . msg_tot a  I [ 4 ] . num_packet s  * 

ug[ vg_num] . msg_t ot a  I [3] . num_packet  s  ♦ 
vg[ vg_num ] . msg_t ot  a  I [2 ] . num_packe t s ; 
num_packets_queued[5]  3  num_packet s_queued[ I J ; 
num_packet s_queued[ 6 ]  3  num_pocket s_queuedt 2] ; 
num_pocket s_queued[ 7]  =  num_packet s_queued[ I ] ; 

/*  For  each  minor  frame,  establish  hoe  many  rate  groups  should  have  */ 

/*  encountered  frame  boundaries  at  the  beginning  of  the  given  minor  */ 

/*  frame  (where  the  given  minor  frame  *  is  the  index  number  */ 

num_rate_groups_due [ 0]  3  4; 

num_rate_groups_due[ I ]  3  I; 

num_rate_groups_due[2]  3  2; 

num_rate_groups_due[ 3]  3  I; 
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num_rate_groupa_due!4]  *  3; 
num_rate_groupa_due!5]  =  I ; 
num_rote_groupa_due(6]  »  2; 
num_rate_groupa_due!?3  *  1 ; 

/*  Non,  for  each  minor  frame,  eatabliah  the  delay  due  to  ayatem  V 

/*  overhead  aa  a  function  of  the  intermediate  tally  values  calculated  */ 
/*  aboue  */ 

for( 1  “0;  i  <8;  ♦* i ) 

< 

'*  Delay  due  to  context  switches  for  taaka  completing  in  giuen  frame  */ 
ouerhead! i 3+=  num_taaka_comp I eted[ i  +  1 3  *  delay_data->context_awitch; 

/*  Delay  due. to  acheduling  of  taaka  completing  in  the  previous  frame  */ 
overhead! i ]♦■  num_taaka_completed[ i 3  *  deloy_data->RGD_tak_coef f ; 
overhead! i ]♦“  num_rate_groupa_due! i 3  *  de I oy_dato->RGD_t sk_conat ; 

/*  Delay  due  to  meaaagea  queued  by  taaka  completed  in  previous  frame  */ 
overhead! i ]+=  num_mag_queued[ i ]  *  delay_data->RGO_mag_conat • 
overhead! i ]♦»  num_packet a_queued[ i ]  * 

(de I ay_dat a- > I H_coe f f  ♦  de I ay_data->RGO_rosg_caef f ) ; 

overhead! i ]  +  =  del ay_dat  a- > I  oca  I _ F  DIR; 

overhead! i ]+=  del ay_dat a- > I H_conat ; 

/*  Due  to  the  nature  of  the  delay  data  for  the  RGD,  the  following  */ 

/*  distinction  is  made  to  account  for  aituationa  where  there  are  */ 

/*  no  meaaagea  queued  by  the  taaka  completed  in  the  previoua  frame  */ 
i f (num_packets_queued[ i ]>0)  overhead!! ]+=de I ay_dat o- >RGD_ouera I l_conat , 
elae  overhead! i ]  ♦»  del ay_data->RGD_empty_queue_conat ; 

> 

/*  Check  the  deadlinea  for  the  RG4  tasks  */ 
for ( i  *  0;  i  <8;  **i  ) 

if  (  (overhead!  i  ]  +  vg[vg_num] .  rg_total  [4]  )  >  fllNORFRflllE) 
vg[vg_num] . overrun! i ]  =  VES; 

/*  Check  the  deadlinea  for  the  RG3  tasks  */ 

rg_total  =  (2*vg[ vg_num] . rg_t ot a  I [ 4 ] )  +  vg[ vg_num] . rg_t ot a  I [ 3 ] ; 
i f ( (overhead! 0 3  +  overhead! 1 3 *rg_tot a  I )  >  ( 2*11 1  NORFRRflE ) ) 
vg[ vg_num] . overrun!8]  =  VES; 

i  f ( (overhead! 2 ]+overhead[3 ] *rg_t ot a  I )  >  (2*0  I NORFRRflE  ) ) 
vgt vg_num] . overrun[9]  =  VES; 

i f((overhead[4]+overhead[5]  +  rg_totol )  >  (2*n I NORFRRflE ) ) 
vgtvg_num] . overrun! 1 03  =  VES; 

i f ( (overhead[63  +  overhead[ 7 ] *rg_t ot a  I )  >  (2*N  I  NORFRRflE ) ) 
vg[ vg_num ] . over run! 1 1 j  -  VES; 

/*  Check  the  deadlinea  for  the  RG2  taaka  */ 

rg_total  =  (4*vg[ vg_num ] . rg_t ot a  I [ 4 ] )  ♦  ( 2*vg[ vg_num]  rg_t ot a  I [ 3 ] )  * 
vg[ vg_num] . rg_tot a  I  [  2] ; 

i f ( (overhead! 03 ♦overhead! I ]+overheod[2]*overhead[ J3+rg_totol )  > 
(4*f1IN0RFRflf1E)) 
vg!vg_num] . ouerrun! I  2]  *  VES; 

if((ouerhead[4]+overhead[53+overhead[6j+overhead[? 1 *r g_t ot  a  I )  > 

(4*f1 1  NORFRRflE)) 
vg[vg_num3 • overrun! I  3]  =  VES; 

/*  Check  the  single  deadline  for  the  RGI  tasks  */ 
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rg_total  *  (8*vg[  vg_num] .  rg_t ota  I  [ 4  ]  )  ♦  ( 1*vg[vg_num ]  .  rg_t  ot  o  I  [ 3  J )  • 
(2*vg[ug_nue]  .  rg_tot  a  I  [  2  ] )  ♦  vg[ug_num] ,rg_total [ 1 3; 
i i ( (overhead[0]+overhead[ 1 ]+overhead[ 2 J  + overhead 1 33+ooerheod[ 4  ]♦ 
ouerhead[5 J+overhead[6 }+ overhead! ?]+rg_t  otal ) ><8*n INORFRfinE ) ) 
ug[vy_nu»] . overrun! 14]  «  VES; 

/*  Record  the  overhead  data  in  the  vg  record  */ 
for(i  «0;  t  <8;  *+i ) 
vg[vg_nu«] . overhead! i ]  *  overheadji]; 

) 

} 

/*  fit  the  close  of  this  procedure,  all  results  are  stored  in  the  vg  */ 

/*  records  and  lent  back  to  the  "moin"  for  interpretat ion  by  mrite_file  */ 
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CALLNAflE:  REAO.LIST 
AUTHOR:  S.  Treoduiel  1 
CREATED:  13  APR  92 
UPDATED:  15  JUN  92 

This  procedure  incorporates  info  held  in  external  files  into  the  run-time 
data  base  for  the  analysis  tool.  "key.uiords .  dot "  holds  the  critical 
constructs  that  are  the  key  to  parsing  the  Ado  code.  "constants . dat "  holds 
the  system  specific  delay  data  that  is  needed  for  doing  ouerrun  calculations 
and  path  parameter i zat i on  comparisons. 

. . . . */ 


uo i d  read_l i st (search_l i st , de I ay_data) 
struct  list_info  ‘seareh.l i st ; 
struct  const ant_l i st  *delay_data; 

< 

int  signal  *  0; 
int  ualue  =  0; 
int  num  *  0; 
int  k; 

int  dummy.int; 

char  dummy_st r i ng[ 1 00 3 ; 

FILE  *1 i st _f i le; 

I  i  st _ f  i  I  e  =  fopen(  "key.uiords  .  dat " ,  “r" ) ; 

i f  < I i st _ f i le  ==  NULL) 

( 

pr  i  nt  f  (  “Cannot  open  key_uiords.dat  for  input\n“); 
ex i t (2) , 

} 

/*  Note  that  file  format  has  each  critical  construct  on  its  oum  line  V 
mh i I e( s i gna I  ! =  EOF ) 

s i gna I  *  fscanf ( I i st.f i I e, ”Xs\n” , search_l i3t->entry[num*»]  name) , 
search_l i st - > I ength  =  num  -  I; 
f  c I ose( I i st_f i I e ) ; 

I i at _ f i I e  =  fopen( "constants . dat  ",  “r" ) ; 

if  (I  ist.fi le  ==  NULL) 

( 

pr i nt f ( "Cannot  open  constants.dat  for  input\n“); 
ex i t (2) ; 

} 

/*  File  format  has  a  label  followed  by  the  related  integer  ualue  Each  */ 

/*  label/ualue  pair  occupies  its  own  line  */ 

fscanf (I  ist.fi le," Xs  Xd\n" , dummy.str i ng , 8. dummy. i nt ) ; 

de lay_data->queue_coef f  =  dummy.int; 

f scanf (I  isl.fi le," *s  *d\n" , dummy.str i ng , idummy.i nt ); 

de lay_data->queue_const  =  dummy.int; 

f scan f ( I  ist.fi le,"Xs  ld\n”, dummy.str i ng , 8,dummy_i nt ) ; 

de I ay.dat a- >ret r i eue.coe f f  =  dummy.int; 

f scan f ( I  ist.fi le, “Is  Xd\n", dummy.str i ng , tdummy.i nt ) ; 

de I ay.dat a->ret r i eue.const  =  dummy.int; 

f scan f ( I  ist.fi le," Is  Xd\n", dummy.str i ng , ILdummy.i nt ) ; 

de I ay.dat a-> I H.coe f f  *  dummy.int; 

f  scan  f(l ist.fi le," Is  Xd\n", dummy.str i ng , &  dummy. i nt ) ; 
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delay— data- > I H—const  =  dummy— int  ; 

f scanf  ( I  i  st_f  i  I  e ,  "Xs  Xd\n” ,  dummy— str  i  ng ,  &dummy_ i  nt ) 
de  lay— data->RGO_ msg_coef  f  =  dummy_int; 
f  scanf  (I  i  st— f  i  I  e ,  “Is  Xd\n"  ,  dummy— str  i  ng  ,  8,  dummy— i  nt ) 
de I ay_ data->RGD— msg_ const  *  dummy— int; 

f scan f ( I i st_f i I e, “Xs  Xd\n " , dummy— str i ng, &dumny _ i nt ) 

de lay_data->RGO_tsk_coef f  =  dummy_int; 
f  scanf  ( 1 i st_ f i I e, "Xs  Xd\n"  ,  dummy— str i  ng ,  8dummy_i  nt ) 
delay— data->RGO_tsk— const  =  dummy— int; 

f  scanf  (I  i  st _ f  i  I  e ,  “Xs  Xd\n " ,  dummy— str i  ng  , &dummy— i  nt ) 

delay— data->RGO_overal l_const  =  dummy-int; 
f scanf ( I i st_f i I e, “Xs  Xd\n" , dummy— str I ng,8dummy_int ) 
de lay— data->RGO_ empty— queue— const  =  dummy- i nt ; 
f scanf ( I i st_f i I e, “Xs  Xd\n" , dummy— str i ng, 8. dummy— i nt ) 
de  I  ay_dat  a->cont  ext_ siu  i  t  ch  =  dummy—  int; 
fscanf(l ist-fi le,“Xs  Xd\n " , dummy— str i  ng,8,dummy_i  nt ) 
delay-data->local_FOIR  =  dummy_int; 
f scanf ( I i st_f i I e, “Xs  Xd\n" , dummy-str i ng ,&dummy_i nt ) 
delay_data->sys_FOIR  *  aummy_int; 

fc lose( I i st_f i  I  e) ; 

} 
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CRLLNAHE :  GET_l INE 
AUTHOR:  S.  Treadwell 
CREATED:  10  JUH  92 
UPDATED:  18  NOU  92 

Uill  use  the  stream  of  characters  provided  by  the  specified  file  to  assemble 
a  buffer  of  single  word  items  all  of  which  belong  to  a  single  line  of  code. 
The  key  here  is  to  look  for  a  semicolon  as  the  line  terminator,  not  a 
carriage  return.  The  semicolon  is  not  included  in  the  program  statement  and 
all  capital  letters  are  transformed  to  lower  case  letters.  All  white  space 
is  deleted  and  comment  lines  are  recorded  in  a  separate  buffer  using  the  same 
format  as  the  program  statement.  The  program  statement  stored  in  this_line 
is  passed  back  to  parse  to  be  examined  during  model  construct i on ,  The 
comment  held  in  comment_line  is  passed  to  par se_comment  to  extract  any 
programmer  input  included. 

- - - - - - V 


int  get_l i ne(t h i s_l i ne, comment- 1 i ne , inf o_buf fer , i nf i I e , error_f i I e) 
struct  I i st_ i n f o  *this_line; 

struct  I i s t _ info  *comment_l i ne ; 

struct  comment_info  * i nfo_buf fer ; 

FILE  * i nf i I e; 

F I LE  *error_f i I e; 

< 

uoid  parse— comment ( ) ; 

int  k; 

int  c  *  0; 

int  num_word  *  0; 

int  num— comment  =  0; 

int  count  «  0; 

int  signal  =  1; 

char  temp[80]; 

enum  boolean  comment  =  NO; 

enum  boolean  done  *  NO; 

th i s_ I i ne-> I engt h  -  0; 
comment-! ine->length  =  0; 

do 


count  *  0; 
do 

if  ((c  ==  1 \n ' )&&.( comment  ==  VES))  /*  for  "\n”  ofter  a  comment  */ 

< 

comment  *  NO;  /*  the  comment  is  terminated  by  the  carriage  return  */ 
comment—! i ne->marker  »  0; 

/*  Check  the  completed  comment  for  programmer  input  */ 
par se_ comment (comment_l ine, i n  f o_bu  f fer,error_fi le); 

comment_l ine->length  =  0;  /*  Once  checked, the  comment  is  not  needed  */ 

) 

whi le( isspace(c  »  fget c( inf i I e) ) ) ;  /*  kill  the  white  space  */ 

if  (c  **  EOF)  break;  /*  terminate  procedure  upon  end  of  file  */ 

do 

{ 

if((c  >  64 )&& ( c  <  91))  c  ♦=  32;  /*  transform  UPPER  case  to  lower  cose  */ 
if((c  *■  ' ; ' )i&(comment  ==  NO))  done  *  VES;  /*  prog  statement  complete  */ 
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if(ldone)  temp[count+*]  =  c;  /*  add  character  to  word  */ 

} 

wh i le( ! i sspace(c  *  fgetc< inf i le) )) ; 
if  (c  ■■  EOF)  break; 

temp[count ]  *  ' \0 ‘ ; 

/*  add  word  to  line*/ 

atrcpy (thi s_l i ne->ent ry[ th i s_l i ne- > I ength] . name ,  temp) ; 
strcpy (comment _ I i ne->entry [comment _l i ne-> I ength] . name, temp) ; 

if  ((k  »  strncmpft emp, “ — ”,2))  **  0)  comment  =  VES; 
if  (conment)  ++comment_l ine-> length; 
else  ♦♦thi s_l ine-> length; 

} 

while  ( ! done) ; 

if  (c  ==  EOF)  signal  =  0; 
t  h i s_ I ine->marker  =  0; 

/*  Uhen  signal  is  returned  as  a  “0,"  it  signifies  that  the  end  of  the  fi 
/*  has  been  reached. 
return(signal ); 


le  */ 

*/ 
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/* . — - - 

CALLNflflE :  SERRCH 
AUTHOR :  S .  Treadwe  1 1 
CREATED:  11  APR  92 
UPDATED:  18  HOU  92 

Uill  do  the  primary  parsing  for  the  "finish"  stage.  Once  a  line  of  code  is 
available  for  analysis,  'search'  uill  inspect  it  for  a  given  list  of  ado 
constructs  and  system  calls  and  will  branch  to  other  parsing  and  analysis 
functions  as  dictated  by  what  is  found.  This  procedure  looks  for  call  names 
and  ada  constructs  exactly  as  given  by  the  user  in  auxiliary  files.  Uhen 
searching  for  matches,  names  that  are  similar  but  not  exactly  the  same  as 
the  names  sought  will  not  be  sufficient  to  warrant  a  match. 


vo i d  search(search_l i st , de I ay_data, ske I et on, thi s_l i ne, f I ags, end_l i st , 

i n  f O— bu f fer , pkg_name , t  ask_name , messages , procedures.fi lename, 


error_f i I e ) 

struct  I i st _ info  *search_l ist ;  /*  list  of  constructs  •/ 

struct  const  ant  — I i st  *delay_ data;  /*  list  of  system  specific  delay  data  */ 

struct  model_info  *skeleton;  /*  holds  the  current  model  */ 

struct  list-info  *this_ line;  /*  current  program  statement  */ 

struct  flag— list  *flags;  /*  parsing  status  info  */ 

struct  list— info  *end_ list;  /*  nesting  status  info  */ 

struct  comment— info  * i nf o_ buf fer ;  /*  programmer  provided  info  */ 

char  pkg_name[]; 
char  task— name[]; 

struct  message— I i m i t s  messages;  /*  message  passing  limits  */ 

struct  proc_l i st— i nfo  *procedures;  /*  holds  all  subprogram  models  */ 

char  filename!]; 

FILE  *error— file;  /*  error  log  */ 


void  process-l oop( ) ; 
void  end— foundO; 
void  task— found( ) ; 
void  pkg_found(); 
void  proc_ found( ) ; 
int  f ind_paramet er( ) ; 
enum  boolean  va I i d-ca I  I ( ) ; 
int  i , j , k ; 

int  old_num_ counters; 
int  old_length; 
int  value; 
int  previous; 

for( i  *  0;  i  <  t h i s_ I i ne-> I ength ;  ++i)  /*  check  each  word  in  the  statement  */ 

{ 

/*  establish  the  index  for  the  word  that  precedes  the  word  currently  */ 
/*  being  examined  */ 

i  f ( i  >0)  prev i ous  =  i  -  I  ; 
else  previous  *  0; 

for(j  *  0;  j  <  search— I i st -> I ength;  **j )  /*  check  against  critical  const  */ 

if((k=  strcmp(th i s— I ine->entry[ i ]. name, search— I i st - >entry[ j ]. name ) )  ==  Oi 
swi tch( j ) 

{ 

case  UFS:  /*  append  to  current  model  */ 
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ake I eton->entry[ske I et on-) I engt h] . type  =  UFS; 
akeleton->entry[akeleton->length] .uolue  =  UNDEFINED; 

if  ( f I aga->ct r_act i ue)  *+ake I et on- > I engt h;  /*  model  must  be  actiue  */ 
break; 
caae  LOOP; 

/*  ignore  “end  loop"  statements  here  */ 

if  <(k  *  atrcmp(thia_l ine->entry[preuious] .name, “end” ) )  !=  0) 

( 

th i s_l i ne->marker  =  i; 

/*  extract  extra  info  and  add  an  entry  to  the  model  */ 
process_Ioop(ake I et on, end_l iat,thia_line,i n  f o_buf fer , error_f i I e ) ; 
if  (f laga->ctr_act iue)  ++akeleton->length; 

} 

break; 

case  IF:  /*  append  to  current  model  */ 

if  ((k  »  atrcmpf t hi a_l i ne- >ent rylpreu i ous] . name, "end" ) )  !*  0) 

{ 

ake I eton->ent ry[ ske I eton-> I engt h] . t ype  =  IF; 
akeleton->entry[skeleton->length] .ualue  =  UNDEFINED; 
if  ( f Iaga->ctr_act iue)  ♦♦ake I et on- > I engt h; 

/*  update  the  end_liat  */ 

at rcpy (end_l  i at  - >ent ry [ end_l  iat->length++] . name , " i f " ) ; 

) 

break; 
case  ELSE: 

ske I et on->ent ry [ ske I et on-> I engt h] . t ype  =  ELSE; 
ake I eton->ent ry [ ske I et on-> I engt h] . ua I ue  =  UNDEFINED; 
if  ( f I aga- >ct r_act i ue )  ++ske I et on- > I engt h ; 
break; 
case  ELS  I F : 

ake I eton->ent ry [ ake I et on-> I engt h] . type  =  ELSIF; 
akeleton->entry[akeleton->length3 .uolue  =  UNDEFINED; 
if  < flags- >ctr_act iue)  *+ake I eton-> I ength; 
break; 

case  CASE:  /*  ignore  “end  case"  statements  here  */ 

if((k  =  at rcmp( th i s_l i ne->ent ry[preu i oua] . name , “ end" ) )  !=  0) 

< 

f I aga- >enob I e_uihen  *  VES;  /*  guards  against  "exception”  handling  */ 

/*  code  being  included  in  the  model  */ 
ake leton->entry[ske I eton->l enqt h] . type  =  CASE; 
ake I eton->entry[ ake I eton-> I engt h] . ua I ue  =  UNDEFINED; 
if  ( f I aga->ct r_oct i ue)  ++skeleton->length; 

/*  update  the  end_liat  */ 

at rcpy (end_l i at  - >ent ry [end_l ist->length  +  *].name, “case''), 

) 

break; 
case  UHEN : 

/*  add  entry  to  model  only  if  it  belongs  to  a  case  statement  */ 

akel eton->entry[skel eton->length] . type  =  UHEN; 

ake I eton->ent ry [ake I et on- > I engt h ]. ua I ue  =  UNDEFINED; 

if  ( ( f I ags->ctr_act i ue  ==  VES)  &&  ( f I ags- >enob I e_when  ==  VES)) 

♦♦ake I et on- > I ength; 
break; 
case  END; 

t h i s_ I ine->marker  =  i  ♦  I; 

end_found( de I ay_dato, this_line,end_liat,procedure3,flogs,skeleton, 
pkg_name , t  ask_name ,error_fi I e ) ; 

break; 
case  TASK; 
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t  h 1  a _ I ine->marker  =  i  +  I; 

task— f ound( th i s_l i ne, end— I i st , t ask_name, fl  ags, error- fi le); 
break; 

case  PACKAGE : 

th  i  s_M  ne->marker  =  i  ♦  I; 

pkg_f ound(th i s_l i ne, end_l i st , pkg_name , flags, error_fi le); 
break; 
case  PROC; 

1 h i s _ I ine->marker  =  i; 

proc_found(th i s_l ine, end_l i st ,  procedures, flogs,  f i I ename ,  error_f i I e) ; 
break; 
case  BEGIN; 

if  ( ( f I ags->proc_depth  >  0) I  I ( f I ags->task_found  ==  VES)) 
f I ags->ctr_act iue  =  VES; 
break ; 

case  SELECT ; 

i f ( ( k  »  st rcmp(th i s_l i ne- >entry[preu i ous] . name , "end" ) )  !=  0) 
st rcpy (end_l i st - >ent ry [end_l ist->!ength*+], name,  "select"); 
break; 

case  RECORD: 

i f  <  <  k  =  strcmp(th i s_l i ne- >entry[preu i ous] . name, "end" ) )  !=  0) 
st rcpy (end— I i st - >ent ry [end— I ist->length+  +  ] .name, "record" ) ; 
break ; 

case  ACCEPT: 

s t rcpy (end- 1 ist->entry[end_l ist->length++], nome , "start ") ; 
break; 

defaul t :  break; 

} 

/*  Need  a  separate  comparison  statement  to  deal  specifically  with  the  */ 

/*  message  passing  functions  because  there  could  be  a  (  and  parameter  */ 

/*  names  attached  to  the  function  call  which  would  cause  an  inexact  */ 

/*  match  with  the  key  word  in  search-list  */ 

i f((k=  strncmp(thi s_l ine->entry[ i ] . name, search— I i3t->entry[j ]  name, 
st r I en(seorch_l i st - >ent ryl j ] . name ) ) )  ==  0) 

( 

this— I ine->marker  =  i; 
search_l i st - >marker  =j  ; 
switch( j ) 

( 

case  QUEUE: 

/*  check  to  make  sure  it  really  is  a  subprogram  call  */ 

i f (ua I i d_ca I  I < t h i s _ I ine->entry[i]-name, 

search— I ist->entry[jj. nome)=* VES) 

{ 

ske I et on->entry [ ske I et on- > I ength] . type  =  QUEUE; 

/*  If  programmer  input  specifies  message  size,  use  that  ualue  */ 

/*  ouer  any  other  possible  size  uolues  */ 

ualue  =  i nf o_ buf f er->message_3 i ze; 
i nfo_ buf fer- >message_3 i ze  =  OEFRULT; 
if(ualue  »*  DEFAULT) 

/*  If  programmer  input  does  not  specify  size,  find  the  ualue  */ 
ualue  *  f i nd_paramet er (seorch-l i st , t h i s_l i ne , error_f i I e) ; 

/*  If  no  uiable  ualue  can  be  established,  assume  the  default  */ 
if((ualue  ==  LOST) I  I (ua I ue  >  messages . xm i t_s i ze ) ) 

( 

fprint f(error_f i le, "Assuming  default  size  for  queue_message\n "  ) ; 
skeleton->entry[skeleton-)l ength ]  .ualue  = 
packet ize(messages.xmit-3ize); 
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) 

else 

skeleton->entry[skeleton->length] .value  = 

packet i ze(va I ue ) ;  /*  transform  size  from  bytes  to  packets  */ 
if  ( f I ags- >ct r_oct i ve)  ++skeleton->length; 

} 

break; 

case  RETRIEUE: 

i f (ual i d_ cal I (thi s_l i ne->ent ry[ i ] . name, 

search. I i st->entry[ j ] .  name) == YES) 

{ 

ske I eton->ent ry [ ske I eton-> I engt h] . t ype  *  RETRIEUE; 
value  *  info_buf fer- >message_s i ze; 
i nfo_buf fer- >message_s i ze  =  DEFAULT; 
iffualue  =*  DEFAULT) 

value  =  f i nd_parameter (search_l ist , thi s_l ine, error_f i t e) ; 
if(<value  ==  LOST) I  I ( va I ue  >  messages . xm it_s i ze) ) 

{ 

fpr i nt f (error_f i le, 

“Assuming  default  size  for  ret r i eve_message\n " ) ; 
ske I eton->entry[ske let on->length], value  = 
packet  i  ze( messages . xm i t_s i ze) ; 

} 

e  I  se 

ske I et on->entry[ske I et on-> I ength] . va I ue  = 
packet i ze< va  I  ue) ; 

if  ( f I ags- >ctr_ act i ve )  ++skeleton->length; 

} 

break; 
case  SEND: 

i f (va I i d_ cal  I ( t h i s_l i ne- >ent ry( i ] . name, 

search_l  ist->entry[j  ]  .  name  )*= YES) 

{ 

ske I et on->entry [ ske I et on-> I engt h] . t ype  =  SEND; 
value  =  i n fo_bu f fer- >message_3 i ze; 
info_buf fer->message_3 i ze  *  DEFAULT; 
i f (va I ue  ==  DEFAULT) 

value  =  f i nd_ paramet er ( search-l i St , t h i s_l i ne , error— f i I e ) ; 
if((volue  ==  LOST)  | | (value  >  messages . xm i t_s i ze ) ) 

< 

fpr i nt f (error_f i I e , " Assum i ng  default  size  for  send_message\n " ) 
skeleton->entry[skeleton->length]. value  * 
packet ize(messages.xmit_size); 

) 

else 

ske I et  on- >entry[skeleton->length]. value  = 
packet i ze( va I ue) ; 

if  ( f I ags- >ct r_act i ve )  ++ske I et on- > I engt h; 

) 

break ; 
case  READ: 

i f ( va I i d_ca I  I (thi s_  I ine->entry[  i ] .name, 

search— I ist- >entry[j]. name)** YES) 

< 

ske I eton->entry [ ske I et on- > I engt h] . t ype  *  READ; 
value  *  i n fo_bu f fer- >message_s i ze ; 
info_ buf fer- >message_3 i ze  =  DEFAULT; 
i  ((value  =*  DEFAULT) 

value  *  f i nd_paramet er ( search-l i st , t h i s_l i ne , error_f i I e ) ; 
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if((ualue  ■■  LOST) | | (value  >  messages . xra i t_s i ze ) ) 

< 

fpr i nt f ( error_f i le, "Assuming  default  size  for  read_message\n" ) ; 
ske  I  eton- >ent ry[ ske I eton-> I ength] . ua I ue  = 
packet i ze ( messages . xm i t_s i ze ) ; 

) 

e  I  se 

skeleton->entry[skel eton-> length]. value  = 
packet i ze (ua I ue) ; 

If  ( f I ags- >ct r_oct i ue)  ++ske I et on- > I engt h; 

} 

break; 

default:  break; 

} 

} 

) 

/*  Nou  look  for  subprogram  calls  and  insert  models  as  appropriate  */ 
if  ( f I ags->ctr_act i ue) 

for ( j  =  0 ;  j  <  procedures->length;  **)  ) 
if((k  =  st rncmp( th i s_l i ne- >ent  ry [ i ] . name , procedures- >entry[j ] . name, 
st r  I  en( procedures- >entry[ j ]. name )) )  ==  0) 

{ 

o I d_num_counters  =  ske I et an- >num_count ers ; 
old_length  =  ske  I  eton- > l engt h; 

for(k  =  0;  k  <  procedures- >entryl j ]. ske I et on . I engt h;  »  +  k) 
ske I et  on->ent  ry [ ske I et on-> I engt h++ ]  = 
procedures- >entry[j], ske leton.entry[k]; 
for(k  =  0;  k  <  procedures- >ent ry[ j ]. ske I et on . num_count ers ;  +»k) 
ske I et on->count er_set [skeleton- >num_count ers++ ]  = 
procedures- >en try [ j ] . ske I et on . count  er_set [k ] ; 

/*  adjust  counter-set  index  values  to  accomodote  the  new  entries  V 
f or(k  =  old_length;  k  <  ske I et on- > I engt h ;  ♦  ♦k) 
i f (ske I eton->ent ry [ k ] . t ype  =  =  COUNTERSET) 
ske I et on- >ent ry[k ] . ua I ue  +=  o I d_num_count ers ; 

) 

) 

} 
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/* - - - - 

CflLLNflHE :  PARSE_C0nf1ENT 
AUTHOR :  S.  Treadwell 
CREATED:  12  HAR  93 
UPOATED:  H  I1RR  93 

This  procedure  takes  a  single  complete  comment  as  input  and  extracts  from 
it  any  programmer  input  specifications  included.  The  specs  must  conform  to 
the  established  conventions,  and  any  information  found  is  used  to  updote  the 
info_buffer,  which  is  a  running  list  of  default  values  to  use  as  loop 
iteration  maximums  and  message  sizes. 

- - - - - »/ 

uoid  parse_comment (comment_l ine, i nfo_buf f er , error_f i le) 

struct  I i st _ info  *comment_i ine; 

struct  comment_info  * i nf o_buf f er ; 

F I LE  *error_f i I e j 

{ 

int  evoluateO; 
int  eual_simple_num( ); 
struct  string  key_uiord[5] ; 
int  i ,  j  ,  k ; 

int  value  =  UNDEFINED; 
st rcpy (key_uiord[0]  .name,  "basic"); 
strcpy  (key_uiord[  1  ]  .  name ,  “  for  "  )  ; 
st  rcpy  (key_tuord[2]  .  name ,  "uih  i  le“); 
strcpy(key_uiord[3]  .name,  “message" ) ; 

/*  Check  if  comment  line  conforms  to  programmer  input  convent  ions  */ 
if((k  =  st rcmp(comment_l i ne- >ent ry [ I ] . name, " *" ) )  ==  0) 

( 

/*  if  an  integer  value  is  given  in  the  comment,  evaluate  it  */ 
i f (eva I uat e(comment_l i ne->ent ry [ comment- I ine->length-l ] .  name)  =  =  SITIPLENUn) 
va I ue-eva l_s i mp 1 e_num( comment— I i ne- >ent ry[comment_l ine->length-l]  name), 
for( i  =0;  i  <  4;  ♦♦  i  ) 

i f ( ( k  =  st rncmp(comment_l i ne- >ent ry [2] . name , key_word[ i ]  name , 
str  I  en(key_uiord[  i  ]  .name)-l  ) )  *■  0) 

/*  update  the  appropriate  info  buffer  value  */ 

/*  if  value  is  not  a  positive  integer,  the  default  value  is  assumed  *' 
sui  i  t  ch(  i  ) 

{ 

case  0: 

if  (value  <  0)  value  =  INFINITE; 
i nfo_buf f er- >bas i c_l oop_l i m i t  =  value; 
break ; 
case  1 : 

if  (value  <  0)  value  *  UNDEFINED; 
i nfo_buf fer- >f or_l oop_l i m i t  =  value; 
break; 
case  2: 

if  (value  <  0)  value  =  UNDEFINED; 
info_buf fer->wh i I e_loop_l imit  =  value; 
break ; 
case  3; 

if  (value  <  0)  value  =  DEFAULT; 
i nfo_buf fer->message_s i ze  -  value; 
break ; 

default :  break; 

} 

} 
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/* - 

CALLNANE :  UR  t  TE _ F  I LE 

RUTHOR:  S.  Treadwell 
CREATED:  05  RPR  93 
UPDATED:  28  RPR  93 

This  procedure  sends  the  analysis  results  to  an  external  file  called 
“resu I ts . dat . “  fill  information  is  passed  in  through  the  ug  data  structure. 
The  output  format  is  self-explanatory. 

- - - */ 


uoid  vrite_.fi  le(ug) 
struct  ug_i nfo  ogt]j 
( 

int  i,j,k; 
int  left_ouer; 
int  RG3_left_ouer; 
int  RG2_left_ouer; 
int  RGi_left_ouer; 

F I LE  *out  file; 

outfile  =  fopen( "resu 1 1 s . dat " ,  "w” ) ; 
i f (out  f i le  »=  NULL) 

{ 

pr i nt f ( "Cannot  open  results.dat  for  output\n"); 
ex i t (2) ; 

} 

fpr i nt f (out f i I e , "fl I  I  results  are  given  in  terms  of  m i croseconds . \n" ) ; 
fprint f(autf i le, "The  allotted  minor  frame  time  is  Id . \n\n" ,  fl  I NORFRfinE ) ; 

for( i  =0;  I  <40;  **i) 

( 

i f (ug[ i ] .present  ==  VES) 

{ 

fprintf<outfi le, "RESULTS  for  UG«ld\n",i); 

/*  List  individual  results  for  tasks  */ 
for(j  =  0;  j  <  vg[ i ] . num_t asks ;  ++j ) 

fpr i nt f (out f i I e, "\nTRSK :  Is  RRTE  GROUP:  ld\n" , vg[ i ]. task [ j  ]. name , 
vg[ i ] . task[ j ] ,rate_group) ; 

fpr i nt f (out f i I e , "UORST  CASE  PRTH:  number  of  packets  queued:  Id\n", 
vg[i].task[j], count er_set . num_queued) ; 
fpr i nt f (out f  i  I  e , "  number  of  messages  queued:  ld\n", 

vg[ i ] . task [ j ] , count  er_set . num_msg_queued ) ; 
fpr i nt f (out f i I e , ”  number  of  packets  retrieved:  ld\n", 

vg[  i ] . task [ j ] .count er_set . num_retr i eved) ; 
fpr i nt f (out f i I e , "  number  of  messages  retrieved:  ld\n”, 

vg [i], task [j], count  er_set . msg_ret  r i eved ) ; 
fpr int f (out f  i  I  e, "  number  of  packets  sent:  ld\n", 

vg[ i ] . task! j ] . count er_set . num_sent ) ; 
fpr int f (out f i le,  ”  number  of  pockets  read:  ld\n", 

vg  (i], task [j], count  er_set . num_read) ; 
fpr int f (out f  i  I e, "  minimal  delay:  ld\n", 

vgt i ] . taskt  j ] . count er_set . total _t i me ) ; 

) 

/*  Now  categorize  results  according  to  rate  groups  and  frame  *  *1 
fprintf( out  file, “\nRRTE  GROUP  TOTALS  FOR  APPLICATION  TflSKS\n"); 
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for( j  ■  I ;  j  <  5;  +*j ) 

fpr i nt f (out f i I e, "rate  group  Xd:  Xd\n“ , j , ug[ i ] . rg_tot a  I [ j ] ) ; 
fprintf(outfi I  e, "\nOUERHERD  TOTRLSNn"); 

/*  Create  a  matrix  of  results  to  shorn  the  contribution  from  ouerhead  */ 
/*  and  each  rate  group  for  each  minor  frame.  */ 

for(j  *  0;  j  <  8;  ++j) 

fpr i nt f (out f i le, “minor  frame  Xd:  Xd\n“ , j , ug[ i 3 ■ ouerhead[ j  ] ) ; 
fpr i nt  f (out  file, 

“\nM  I  NOR  FRRtlE  OUERHEfiD  RG4  RG3  RG2  RGIW); 
RG3_I eft_ouer  »  ugt i ] . rg_total [3] ; 

RG2_I eft_ouer  •  ug[ i ] . rg_tota I [2] ; 

RG1_I eft_ouer  =  ugt i ] . rg_tota I [ 1 ] ; 
for( j  =0;  j  <8;  +  +  j ) 

{ 

/*  Determine  whether  a  neui  frame  begins  for  RG3  and  RG2  tasks  */ 
i f ( ( j  ==  2)1  I ( j  ««  4)||(j  -*  6)) 

RG3_I eft_ouer  =  ug[ i ] .rg_tota I [3] ; 

(j  ■■  5) 

RG2_I e ft_ooer  *  ug[ i ] . rg_t ot a  I [2 ] ; 
fpr int f (out f  i  le, "  Xd  “<j); 

/*  ouerhead  contribution  */ 
ifOllNORFRflflE  >=  ugt  i  ]  . ouerheadt j  ] ) 

{ 

fprintf(outfi le,"  X5d",ug[i].ouerhead[j]); 
left_ouer  =  HINORFRAflE  -  ugt  i  ] .  ouerheadt  j  ] ; 

} 

else 

{ 

fpr  i  nt  f  (out  f  i  le,"  X5d" , M I NORFRRUE) ; 
left_ouer  *  0; 

) 

/*  RG^  contribution  */ 
if(left_ouer  >=  ugt i ] . rg_t ot a  I [ 1 ] ) 

{ 

fpr int  f (out  f i I e, "  X5d” , ug[ i ] . rg_total [4 ] ) ; 
left_ouer  -=  ug[ i ] . rg_tota I [ 4] ; 

) 

e  I  se 

{ 

fpr  int  ((out  f  i  le,  ''  X5d”,  left_ouer); 

left_ouer  =  0; 

} 

/*  RG3  contribution  */ 
i f ( I eft_ouer  >=  RG3_left_ouer) 

( 

fprintf(outfile,"  X5d",RG3_le  f  t_ouer ) ; 
left_ouer  -=  RG3_I eft_ouer ; 

RG3_left_ouer  =  0; 

} 

e  I  se 

( 

fpr i nt  f (out  f i I e , "  X5d" , I e f  t_ouer ) ; 

RG3 _ I ef t_ouer  -=  left_ouer; 

left_ouer  =  0; 

5 

/*  RG2  contribution  */ 
if(left_ouer  >=  RG2_left_ouer) 

( 
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fpr i nt  f (out  f i I e , "  X5d“ , RG2—I e f t_ouer ) ; 

left_ouer  -=  RG2_) ef t_over ; 

RG  2 _ i e f t_ouer  =  0; 

} 

e  I  se 

{ 

f print f ( out f  i  le, "  X5d“ ,  I eft_ouer ); 

RG2-I eft_ouer  -  =  left_ouer; 
left_ouer  *  0; 

} 

/*  RG1  contribution  */ 
if(left_ouer  >=  RG1_left_ouer) 

( 

fprintf(outfi le,”  %5d\n“ ,RGI_left_ouer); 

left_ouer  -■  RG 1 _ 1 eft_ouer ; 

RG1_I ef t_ouer  =  0; 

) 

e  I  ae 

{ 

fpr int  f (out f i I e,  “  I5d\n“ , I eft_ouer ) ; 

RG1_left_ouer  -  =  left_ouerj 
left_ouer  =  0; 


/*  State  predicted  ouerrun  condit 
fprintf(outfi 1 e ,  " \n  "  )  ; 
i f (ug[ i ] . ouerrun[0]  ==  VES) 

i  ons 

*/ 

fpr i nt f (out f i 1 e, "RG4  did  not 
i f(ug[ i ]. ouerrun! 1 ]  ==  VES) 

sal 

i  s  fy 

i  t  s 

boundary 

in 

f  rome 

fpr i nt f (out f i 1 e, "RG4  did  not 
i f(ug( i 1 . ouerrun! 2]  ==  VES) 

3Qt 

i  sfy 

i  t  s 

boundary 

i  n 

frome 

f pr i nt f (out f i 1 e , "RG1  did  not 
i f (ug[ i ] . ouerrun[3]  *=  VES) 

act 

isfy 

i  t3 

boundary 

i  n 

frame 

f pr i nt f (out f i 1 e , "RG4  did  not 
i f (ug[ i ] . ouerrun[4]  ==  VES) 

aot 

isfy 

i  la 

boundary 

i  n 

f  rame 

fpr i nt f (out f i 1 e, “RG4  did  not 
i f (ug[  i  ] . ouerrun[5]  ==  VES) 

30 1 

isfy 

i  t  s 

boundary 

i  n 

frame 

fpr i nt f (out f i 1 e , “RG4  did  not 
i f (ug[ i ] . ouerrun[6]  ==  VES) 

sat 

isfy 

i  1 3 

boundary 

i  n 

frame 

fpr i nt f (out f i 1 e, "RG4  did  not 
i f (ugt i ] . ouerrun!?]  ==  VES) 

sat 

isfy 

i  1 3 

boundory 

i  n 

frame 

fpr i nt f (out f i I e , "RG4  did  not 
i f (ug[ i ] . ouerrun[8]  ==  VES) 

sat 

isfy 

i  t  s 

boundary 

i  n 

f  rame 

f pr i nt f (out f i 1 e, "RG3  did  not 
i f (ugT i ] . ouerrun[9]  ==  VES) 

sat 

isfy 

i  1 3 

boundary 

i  n 

f  rame 

fpr i nt f (out f i t e, "RG3  did  not 
i f ( ug! i ] . ouerrun! I 0 ]  ==  VES) 

sat 

isfy 

i  1 3 

boundory 

i  n 

f  rame 

fpr int f (out f i te, "RG3  did  not 
i f (ug[ i ] . ouerrun! II ]  ==  VES) 

sat 

isfy 

i  1 3 

boundory 

i  n 

f  rome 

fpr i nt f (out f i 1 e, ”RG3  did  not 
i f(ug( i ] . ouerrun! 12]  ==  VES) 

sat 

isfy 

i  1 3 

boundory 

i  n 

f  rame 

fpr i nt f (cut f i 1 e, "RG2  did  not 
i f ( ug[  i  ]  .  ouerrun 1 1 3 ]  ==  VES) 

sot 

isfy 

i  t  3 

boundary 

i  r» 

frame 

fpr i nt f (out f i 1 e, “RG2  did  not 
i f (ug[  i  ] . ouerrun! M ]  ==  VES) 

sot 

isfy 

f  1  s 

boundar y 

i  n 

frame 

fpr int f (out f i 1 e, "RGI  did  not 
f pr i nt  f (out  f i 1 e, ”\ f  ” ) ; 

sat 

isfy 

i  1  3 

on  1 y  boundory . \n " 

) 

J 


An"); 
.  \n" ) ; 
An" ) ; 
An" )  ; 
\n"  )  ; 
An" )  ; 
An"  )  ; 
An"  )  ; 
.  \n"  ) ; 
.  \n"  )  ; 
.  \n”  )  , 
■  \n“  )  ; 
An"  )  , 
An"  )  ; 
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/* - - 

CALLNAHE :  UITH_FOUNO 
AUTHOR:  S.  Treadwell 
CREATED:  12  JUt  92 
UPDATED:  08  OCT  92 

This  procedure  is  used  to  help  establish  the  software  hierarchy  for  a  gioen 
task.  Uheneuer  a  “with"  statement  is  found  in  a  context  clause,  it  is  sent 
to  this  procedure  so  that  the  package  name  can  be  extracted  and  added  to 


uo i d  w i t h_found( th i s_l i ne , pkg _ I i st ) 

struct  I i st _ info  *this_line; 

struct  I i st _ info  *pkg_list; 

{ 

i  nt  i ,  c ; 
int  j  =  0; 
i  nt  k  =  0 ; 
int  num  =  0; 

enum  boolean  repeat  =  NO; 
char  tempi [80]; 
char  temp2[80]; 
struct  3tring  package[10]; 

/*  Host  of  the  complexity  of  this  procedure  is  due  to  an  attempt  to  handle  */ 
/*  different  format  styles  for  the  "with"  statement  --  i.e  single  us.  */ 

/*  multiple  names  on  each  line,  with  or  without  white  space  separat i ng  the  */ 
/*  names,  */ 

for( i  *  this_l ine->marker;  i  <  t h i s_l i ne - > I engt h ;  ♦+i) 

{ 

strcpy( tempi , t  h i s _ I  ine->entry[i], name) ; 

while((c  =  temp1[j++])  !=  '\Q') 

{ 

i  f  (c  “  "/') 

{ 

t  emp2[k  ]  =  ‘ \0  '  ; 

if  ( (c  «  tempi [ j  ] )  !  =  '  \0  '  ) 

{ 

k  -  0; 

if  ( st r I en( t emp2 )  >=  1)  st rcpy( package [ num++ ]. name , t emp2 ) ; 

> 

} 

e  I  se 

temp2[k**J  =  c; 

) 

temp2[k]  *  '\0'; 

if  (st r I en( t emp2  )  >=  I)  st rcoy( package [ nun**  ]. name , t emp2 ) ; 

j  *  0; 

k  =  0; 

) 

/*  Ensure  that  package  names  are  not  repeated  within  pkg_list  V 
f  or ( i  «  0 ;  i  <  num ;  ♦♦  i  ) 

{ 

repeat  *  NO; 

for(j  *  0;  j  <  pkg_l ist->length;  **j) 

if((k  =  St rcmp(pockage [ i ]. name , pkg_l ■ ut - >ent ry[ j ]. name ) )  --  0) 
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repeat  ■  YES; 
if(repeat  ==  NO) 

strcpy(pkg_l ist->entry[pkg_! t  a  t  —  > I engt h*+ ] . name, package! i ] . name) ; 

} 


CALLNANE :  PKG-FOUND 
AUTHOR:  S.  Treadwell 
CREATED:  06  OCT  92 
UPDATED:  06  NOU  92 

In  the  case  where  a  package  statement  is  found,  this  procedure  will  decide 
whether  it  is  a  ualid  package  body  and  ensure  that  the  name  matches 
the  name  expected.  If  these  conditions  pass,  the  proper  flag  will  be  set. 
- - V 


uo i d  pkg_found( th i s _ I i ne , end_l i st , pkg_name .flags, error_f i I e ) 

struct  list-info  *this_line; 

struct  list_info  *  end _ list; 

char  pkg_name[ ] ; 

struct  f I ag _ list  *flags; 

F I LE  *error_f i I e ; 

{ 

i  nt  k ; 

if  (<k  •  strcmpfth i s_l ine- >entry[ th i s_l i ne- >marker ++ ] . name, "body" ) )  =  =  0) 

( 

/*  In  the  case  where  the  task  body  file  is  being  processed  the  package  */ 
/*  name  is  not  known  prior  to  processing  and  is  defined  as  "none" 

/*  llhen  the  package  name  is  found  it  is  appropr i ate  I y  recorded  */ 

if  ((k  =  strcmp(pkg_name, "none" ) )  ==  0) 
strcpy(pkg_name, thi s_l ine->entry[this_l ine->marker] . name ) ; 
if  ((k  *  strcmp(pkg_name , th i s_l i ne- >ent ry[ t h i s_l i ne->marker ] . name) )  ==  0) 
{ 

f lags->pkg_found  =  YES; 

st rcpy (end_l i st->ent ry[end_l i st -> 1 engt h++ ] . name , pkg_nome ) ; 

} 

e  I  se 

f pr i nt f (error— f i I e , "Unexpect ed  package  name  or  instance  found\n"), 

} 

> 
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CflLLNflnE:  TASK-FOUND 
AUTHOR :  S.  Treadwell 
CREATED:  06  OCT  92 
UPDATED:  12  NOU  92 


In  the  case  inhere  a  task  statement  is  found,  this  procedure  ui  i  I  I  decide 
whether  it  is  a  task  body  and  ensure  that  the  name  matches 
the  name  expected.  If  these  conditions  pass,  the  proper  flog  will  be  set. 
- - - - - */ 


uo i d  t  osk_found (this— I i ne , end— I ist,t  ask— name ,flags, error— fi le) 

struct  list— info  *this_ line; 

struct  list_info  *end_list; 

char  task— name[]; 

struct  flag-list  *flags; 

F I LE  *error_ f i I e; 

( 

i nt  k; 

if  ((k  »  strcmp( t h i s_ I  i ne- >ent ry [ t h i 8— I i ne- >morker  +  + ] . name , " body "  )  )  =  =  0) 

{ 

st rcpy (end— I i st ->ent  ry [end— I ist->length++]. name, 
this-l ine->entry[this_l ine->morker]  .name); 
if  ((k  ■  st rcmp(th i s_ I i ne- >entry[th i s_l i ne- >marker ). name , t ask-name ) )  - s  0) 
if  (  f  I  ags->pkg_ found  ==  VES)  f  lags-Mask— found  =  VES; 
else  fpr int f(error_ f i le, "Task  found  but  package  not  yet  found\n"); 
else 

fpr i nt f (error— f i I e, "Unexpected  task  name  --  found:  Xs  expected:  Xs\n”, 
t h  i  3_ I  i  ne->ent  ry[ t h  i  s-l  i  ne->.*arker  )  .  name ,  task-name ) ; 

) 


} 


CRllNRME:  PACKET  I ZE 
AUTHOR:  S.  Treadwell 
CREATED:  20  APA  93 
UPDATED:  20  APR  93 

A  simple  function  to  transform  a  message  size  in  bytes  to  a  message  size  in 
61-byte  packets.  Note  that  four  bytes  of  ooerhead  are  added  to  the  message 
size  to  account  for  message  header  information. 

- - - */ 


int  packet ize(num_bytes) 
int  num-bytes; 

{ 

int  num-packets; 
num-bytes  ♦*  1; 

num_packet3  =  ce i I (num_bytes/61 , 0) ; 
return(num_packet  s ) ; 

} 
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/* - - 

CALLNAME :  PROC.FOUNO 
AUTHOR :  S.  Treadwell 
CREATEO;  15  JUL  92 
UPDATED:  10  NOU  92 

Grabs  the  name  of  a  procedure  and  increments  both  the  length  of  the  procedure 
list  and  the  internal  procedure  marker . 

- - - - */ 


uo i d  proc_found(th i s_l i ne, end_l i st , procedures, flags, f i I ename, error_f i I e ) 

struct  I i st_ info  *this_Iine; 

struct  list_info  *end_list; 

struct  proc_l i st_i nfo  ‘procedures; 

struct  flag_list  ‘flags; 

char  f i I  enamel ] ; 

F I LE  *error_f i I e; 

( 

int  i  =  0; 
i nt  c, k; 
char  te»p[80]; 
char  name[40); 

/*  The  proc_depth  flag  is  needed  to  help  identify  ua I i d  subprogram  body  */ 
/*  code  so  that  extraneous  code  is  not  included  in  the  model.  Basically  */ 
/*  when  proc_depth  is  greater  than  zero,  we  are  dealing  uiith  code  inside  */ 
/*  a  subprogram  body  and  can  add  model  entries  appropriately  */ 

i f ( f I ags->pkg_found  ==  VES)  +  +f lags->proc_depth; 

/*  Extract  the  name  of  the  procedure  and  strip  away  the  parameter  list  V 
strcpy(temp,this_l ine->entry[this_l ine->marker  ♦  I], name); 
c  ■  temp[0]; 

while((c  I*  '  \Q ' )  8.8.  (c  !■  ’(')) 

{ 

name[i++]  =  c; 
c  =  tempt  i  ] ; 

) 

nameti]  =  ‘ \0 ' ; 

/*  Set  up  the  procedures  data  structure  to  accept  model  info  */ 
strcpy(end_l i st->entry[end_l i st-> I ength++] .name.nome); 
s trcpy( procedures- >entry [procedures-) I engt h] . name , name) ; 
strcpy (procedures- >entry[procedures->length] . fi I ename .filename); 
procedures->entry [procedures- > I ength] . done  •>*  NO; 
procedures->marker  •=  procedures- >  I  engt  h ; 

♦♦procedures- > I ength ; 

) 
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CALLNANE :  F I  N0_PARAf1ETER 
AUTHOR :  S.  Treadwell 
CREATED:  1  OAV  92 
UPOATED:  30  OCT  92 

Once  a  system  call  is  found,  it  may  be  necessary  to  calculate  the  delay  it 
incurs  based  upon  the  ualue  of  one  of  the  parameters  included  in  the  call. 
This  procedure  will  identify  all  of  the  parameters  for  a  giuen  call,  and 
the  critical  parameter  can  be  isolated  and  eualuated  with  reference  to  all 
preceding  code.  The  object  is  to  attach  a  specific  ualue  to  the  critical 
parameter  so  that  this  ualue  can  be  used  in  calculating  the  expected  time 
delay  for  a  giuen  system  call.  For  now,  this  procedure  is  only  utilized 
when  trying  to  determine  the  size  of  a  message  far  a  message  passing  fen. 
- - - »/ 


i nt  f i nd_paramet er (search.. I i s t , t h i s _ I ine, error_f i I e ) 

struct  I i s t _ info  *search_l i st ; 

struct  I i st _ info  *thi3_line; 

F I lE  *error_f i I e ; 

{ 

int  eualuateO; 

ini  eua I _s imp  I e_num( ) ; 

int  eua l_comp I ex_num( ) ; 

int  eua l_natura l_num( ) ; 

int  c; 

int  i  *  0; 

int  j  =  0; 

int  k  *  0; 

int  num  =  0; 

int  ualue  «  LOST; 

enum  boolean  foundfirst  =  NO; 

enum  boolean  foundsecond  =  NO; 

enum  boolean  innerset  =  NO; 

char  tempi [40]; 

char  temp2[10]; 

char  cr it ical [40]; 

struct  string  parameter [ I  0] ; 

/*  Most  of  the  complexity  of  this  procedure  is  due  to  an  attempt  to  handle  */ 
/*  any  possible  parameter  list  format  --  to  include  white  space  and  euen  */ 
/*  carriage  returns  between  parameters,  */ 

for( i  *  t h i s _ I ine->marker;  i  <  t h i s_l i ne- > I engt h ;  ♦  ♦i) 

< 

st repy ( t emp I , th i s_l i ne- >ent ry [ i ] . name ) ; 
while((c  »  tempi [j ♦+] )  !=  '\0’) 

( 

swi tch(c) 

{ 

case  /*  Looking  for  the  (  that  begins  the  parameter  list  */ 

if  (foundfirst  **  VES)  /*  in  case  of  parameter  like  "natural(i)"  */ 

( 

innerset  «  VES; 
temp2[k*+]  *  c; 

} 

else  foundfirst  =  VES; 
break ; 

case  /*  commas  separate  the  parameter  items  V 
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te«p2[k]  *  ‘ \0 ' ; 

3trcpy( parameter [num] . name , t emp2 ) ; 

k  -  0; 

♦■•■num; 

break; 

case  /*  Looking  for  the  closing  )  */ 

i f  ( innerset  »=  VES) 

{ 

temp2[k++]  =  c; 
innerset  ■  NO; 

} 

e  I  se 

{ 

faundsecand  =  VES; 
temp2[k]  *  ‘ \U ' ; 

s trcpy( parameter [num] .name,temp2) ; 

} 

break; 
defau I t : 

if  (foundfirst  ==  VES) 
if  ( ! i sspaceCc ) ) 
temp2[k»*]  =  c; 
break; 

} 

} 

j  =  0; 

> 

/*  Note  thot  the  fourth  parameter  is  targeted  because  it  is  the  fourth  */ 

/*  parameter  that  specifies  message  size  for  message  passing  functions  */ 

/*  In  the  future,  uie  can  pass  in  the  number  of  the  critical  parameter  *7 
/*  rather  than  hauing  it  hardwired  to  =  1  */ 

i f  (num  >■  3) 

strcpy(cr i t ical , paramet er [ 3 ] .name) ; 
e  I  se 

fpr i nt f (error_f i I e, “Found  too  few  parameters  for  an  instance  of  ls\n', 
search_l i st ->ent ry [ sear ch _ I ist->marker].name); 

/*  Determine  the  format  of  the  critical  parameter  and  eualuate  if  possible  */ 
switch(eualuote(crit ical  )) 

< 

case  SINPLENUM:  uatue  =  eua l_s i mp I e_num(cr i t i ca I ) ;  break; 
case  COnPLEXffUfl:  ualue  *  eual_compIex_num(crit  ical );  break; 
case  NflTURfiLNUfl:  ualue  =  eool_natural_nuin(crit ical );  break; 
case  URRNRI1E:  ualue  =  LOST;  break; 
case  UNKHOUN:  ualue  =  LOST;  break; 

) 


if  (ualue  <  0)  ualue  =  LOST; 
return(ualue); 
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/* . 

CflLLNfiflE :  PROCESS-LOOP 
AUTHOR :  S.  Treadwell 
CREATED:  23  JUL  92 
UPDATED:  18  HOU  92 


Dill  take  a  "loop"  occurrence  and  further  define  it  into  the  type  of  loop  or 
classify  it  as  an  "end  loop."  If  the  program  statement  defines  the  beginning 
of  a  loop,  the  ualue  of  the  loop  iterations  maximum  must  be  defined  and 
included  in  the  appropriate  model  entry. 


*/ 


uo i d  process— I oop(ske I et on, end- I ist,this_l ine, i nf o_ buf f er , error_f i I e ) 
struct  model— info  ‘skeleton; 

struct  list— info  * t h i 3 _ line; 

struct  list-info  *end_iist; 
struct  comment— info  *info_buffer; 

F I LE  ‘error— f i I e; 

< 

int  for— I oop_found( ) ; 
enum  boolean  target_found( ) ; 
int  k ; 

/*  Update  end-list  according  to  the  loop  construct  */ 
st rcpy (end— I i st - >ent ry[end_l i at  —  > I ength  +  + ] .name," loop") ; 
ske I et on->ent ry [ ske I et on-)  I  engt h  ] .  ua I ue  =  UNDEFINED; 

/*  Is  it  a  for . , I oop?  */ 

if  (target-found(th i s-l i ne, " for loop" )  ==  VES) 

( 

ske I eton->ent ry [ ske I et on-> I ength ] . type  =  FOR— LOOP; 
ske leton->entry[skeleton->length].ualue  = 

for- 1 oop_ f  ound( t h i 3_l ine, i nfo_bu  f  f  er , error— f i I e) ; 

} 

else  /*  Is  it  a  whi I e . . I oop?  */ 

{ 

if  (t  arget— f  ound(  t  h  i  3_l  i  ne ,  "tiih  i  I  e" , "  I  oop" )  ==  VES) 

( 

ske I et on- >ent ry[ ske I et on- > I engt h ] . t ype  =  U  H I L  E  _L  OOP; 

ske  I  et  on  -  >ent  ry[skelet on ->length]. ualue  =  inf  o_ bu  f  fer-  >iuh  I  I  e _ I  o  o  p_  I  i  m  .  t  , 

i  nfo_ buf  fer->uih  i  I  e_l  oop_l  i  m  i  t  =  UNDEFINED; 

) 

else  /*  «ie  know  it  is  a  basic  loop  at  this  point  */ 

{ 

sketeton->entry[skeleton->length] . type  =  LOOP; 

ske I et on->ent ry[ske let on ->length]. ualue  =  i nf  o_bu  ffer->basic_loop_l imit ; 
i nfo_ buf fer->bas i c_l oop_l i m i t  =  INFINITE; 

} 

) 


} 
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/* . . . - - - 

CflLLNflnE :  FOR_LOOP_FOUHD 
AUTHOR :  S  .  Treaduie  I  I 
CREATED:  4  flflV  92 
UPDATED:  29  JUL  92 

If  a  for.,  loop  construct  ia  found,,  the  loop's  max  iterations  must  be  defined 
and  stored  in  the  ualue  element  of  the  model.  This  procedure  checks  the 
programmer  input  buffer,  and  if  no  limit  is  giuen  there,  it  finds  the  loop 
argument  and  attempts  to  evaluate  it. 

- - - */ 


int  for_loop_found(th i s_l ine, i nfo_buf fer, error_f i le) 
struct  list_info  *this_line; 
struct  comment_i nfo  * i nfo_buf fer ; 

{ 

int  eualuateO; 

int  eua l_range_num( ) ; 

struct  range_info  tempronge; 

char  argument  [  20] ; 

int  I oop_l i m i t  *  UNDEFINED; 

/*  Identify  the  loop  argument  */ 

strcpy (argument , th i s_l i ne- >entry[th i s_l i ne->marker  ♦  3]. name); 

/*  If  there  is  no  programmer  input  for  the  loop  maximum  evaluate  the  */ 

/*  argument  if  possible  */ 

if  ( i nfo_buf fer->for_loop_l imi t  ==  UNDEFINED) 
if  (eua  I  uat  e(argument  )**  RflNGENUfl) 

t  oop _ limit  =  eva l_range_num(argument , error_f i I e) ; 

i f ( I oap _ limit  <  0)  /*  If  no  positive  integer  is  established  for  limit  V 

( 

I aop_ limit  =  i nfo_bu f f er->for_l oop_l i m i t ; 
in fo_buf fer- >for_l oop_l i m i t  =  UNDEFINED; 

> 

return( I oop_l i m i t ) ; 

} 
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CALLNAHE :  END-FOUND 
AUTHOR:  S.  Treadwell 
CREATED:  15  JUL  92 
UPDATED:  18  NOU  92 

This  procedure  is  used  for  any  “end"  statement  found  and  it  is  essential  to 
maintaining  the  end— list,  which  holds  code  nesting  status  info.  For  "end" 
statements  applying  to  program  units,  this  procedure  initiates  the  model 
wrap-up  and  processing. 

- - - - */ 


uo i d  end_found(de I ay_data, t h i s _ I i ne, end_l ist, procedures, flags, skeleton, 

pkg_name, task_name, error_f i le) 
struct  constant-list  *delay_data; 
struct  list_info  ‘this_line; 
struct  list— info  ‘end— list; 
struct  proc_ I ist_ info  ‘procedures; 
struct  flag— list  ‘flags; 
struct  model— info  ‘skeleton; 
char  pkg_name[]; 
char  task_name[]; 

F I LE  ‘error— f i I e; 

{ 

uoid  reduce— mode  I <) ; 
int  i,j,k; 

char  dummy— name[ 80] ; 
char  object[80]; 
char  expected[80] ; 

i  *  procedures->marker ; 

strcpy(expect ed, end_l i st ->ent ry [end_l i st - > I ength  -  1].name); 

/*  If  “end"  is  the  last  word  in  the  program  statement...*/ 
i f(this_l ine->marker  <  this_l ine->length) 

strcpy(obj ect , th i 3_ I  ine->entry[this_l  i ne->marker  ] . name) ;  /**/ 
e  I  se 

strcpy(obj  ect , “none" ) ; 

/*  Compare  what  end— list  expects  with  what  is  found  in  the  code.  If  there  */ 
/*  is  a  mismatch,  declare  a  fatal  error.  */ 

if((k  =  strcmp(obj ect , end— I i st - >entry [end_l i st -> I engt h  -  1].name))  !*  0) 

if((k  -  strcmp(obj ect ,  “none" ) )  !=  0)/*  don't  compare  something  to  nothing*/ 

{ 

f lags->fatal_error  =  VES; 

f pr i nt f (error_f i I e , "Fata I  error  occurred  in  package  Xs  with  end  Is'", 

Dkg_roT.!. ,  j  ; 

fpr i nt f (error_f i le, "...  expect i ng  end  Xs\n", 

end_l i st- >entry[end_l ist->length  -  I], name); 

> 


/*  If  the  end  of  a  subprogram  body  is  found...  */ 
if((k  *  strcmp(expected,procedures->entry[ i ] .name) )  =  =  0) 

f 

i f ( f I ags->proc— depth  >  0)  --f lags->proc_ depth; 

else  fpr i nt f (error_f i I e , "Error  with  procedure  depth\n“); 

f I ags->ctr_act i ue  =  NO;  /*  deactivate  the  model  */ 
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reduce_mode I (ske I eton, de I ay_data, error_f i I e) ;  /*  uirap-up  the  model  */ 
procedures->entry[ i ] . ske I eton  -  ’skeleton;  /*  store  the  model  */ 
procedures->entry[ i ] . done  =  VES; 

skeleton->length  =  0;  skeleton->num_counters  =  0; 
procedures->marker  =  procedures- > I ength ; 

/*  Must  account  for  nested  procedure  bodies  */ 
for  (j  ■  procedures->marker  -  1;  j  >=0;  — j ) 

( 

i f (procedures->entry[ j ] , done  ==  NO) 

{ 

procedures->marker  =  j; 
break; 

} 

) 

} 

/*  If  the  end  of  a  package  is  found,..  */ 
if((k  ■  stremp(obj ect , pkg_name) )  ==  0) 

{ 

f I ags->ctr_act i ue  =  NO;  /*  deactiuate  model  */ 
f I ags-> f i n i shed  =  VES;  /*  code  processing  is  complete  */ 
for(j  =  0;  j  <  procedures->length;  **j ) 
procedures->entry[ j ] .done  =  VES; 

/*  adjust  subprogram  names  to  include  package  name  */ 
for(j  =  procedures->pkg_marker;  j  <  procedures-> length;  +*j ) 

( 

strcpy<dummy_name, pkg_name) ; 

Strcat (dummy_name, " . “ ) ; 

st  rcat  ( dummy_noine  ,procedures->entry[j  ]  .name) ; 
st  rcpy (procedures- >ent  ry[ j ] . name , dummy_name ) ; 

} 

procedures->pkg_morker  =  procedures-Xength; 

} 

/*  If  the  end  of  a  task  body  is  found...  */ 
if((k  «  st rcmp( ob j ect , t 03k_name ) )  ==  0) 

( 

f I ags- >ct r_act i ue  =  NO; 
f I ags- > f i n i shed  =  VES; 
for(j  =  0;  j  <  procedures- > I ength;  +  +  j  ) 
procedures->entry[ j ]  .  done  =  VES; 

) 


/*  Add  an  end_loop  entry  to  the  model  */ 
if((k  =  strcmp( expect ed I oop" ) )  -=  0) 

< 

if((k  *  strcmp(obj ect , "none" ) )  ==  0) 

fpr i nt f (error_f i I e, "Fata  I  error  --  expecting  on  end  loop\n"); 
ske I et on- >ent ry [ ske I e t on- > I engt h ] . t ype  =  END_L00P; 
ske I et on- >ent ry [ ske I et on- > I engt h ] . ua I ue  =  UNDEFINED; 
if  ( f I ags->ct r_act i ue )  ++ske I et on- > I engt h; 

> 

/*  Add  an  end_if  entry  to  the  model  */ 
if((k  =  stremp(expected, “ i f " ) )  =«  0) 

( 

if((k  =  strcmp(obj ect , “none" ) )  ■»  0) 

f pr i nt f (error_f i I e , "Fat  a  I  error  --  expecting  an  end  if\n"), 
ske I et an->ent ry [ ske I et on- > I engt h] . t ype  =  END_IF; 
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ake I eton->entry[ske I et on-> I ength] . ua I ue  *  UNDEFINED; 
if  ( f I ags->ctr_act i ue )  ++ske I et on- > I engt h; 

> 

/*  Add  an  end_case  entry  to  the  model  */ 

if((k  »  st rcmp(expect ed, “case  “ ) )  »»  0) 

( 

if((k  »  strcmp(object, "none"))  =  =  Q) 

f  pr  i  nt  f  ( error_f  i  I  e , Fat  a  I  error  --  expecting  on  end  case\n"); 
skeleton->entry[skeleton->length].type  =  END_CRSE; 
ske I et on->entry[ske I et on-> I engt h] . ua I ue  *  UNDEFINED; 
if  ( f I ags->ctr_act i ue)  *+ske I et on- > I engt h; 
f I ags- >enab I e_»hen  »  NO; 

> 

if((k  «  strcmp(expected , “start “) )  ==  0) 
if((k  “  strcmpfobj ect , "none" ) )  --  0) 

f pr i nt f (error_f i I e , "Fat  a  I  error  --  expecting  an  end  start\n"), 

if((k  *  st rcmp( expect ed ,  “se  I  ec t  “ ) )  **  0) 
if((k  =  strcmp(obj ect , "none" ) )  ==  0) 

f pr i nt f ( error_f i I e , " Fat  a  I  error  --  expecting  an  end  selectNn"); 

i f ( ( k  »  st rcmp( expect ed record ") )  «*  0) 
if((k  ■  strcmpfobj ect , “none" ) )  ==  0) 

f pr i nt f ( error_f i I e , “Fa t a  I  error  --  expecting  an  end  record\n"); 

i f (end_l i st - > I engt h  >  0)  -~end_l i st - > I ength; 


) 
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/* - 

CALLHRDE :  UALIO_CALL 
AUTHOR :  S.  Treaduiel  I 
CREATED:  22  JUH  92 
UPDATED:  22  JUH  92 

A  quick  check  to  see  if  a  procedure  call  instance  i3  really  a  ua  I  i  d  one. 
Basically  this  traps  for  cases  ishere  there  is  a  larger  word  that  contains 
the  name  of  a  procedure  but  is  not  a  call  for  that  procedure. 

. . . . . »/ 


enum  boolean  ual id_cal I (argument .match) 
char  argument[]; 
char  match[]; 

{ 

i  nt  k ; 

enum  boolean  flag  =  NO; 

i f (str I en(argument )  "=  st r  I  en( mat ch) )  flag  *  VES; 
if((k  *  argument [ st r I en( mat ch) ] )  ==  '(')  flag  *  VES; 

returnf  flag); 

} 

/* - - - - - - - . — . - 

CALLNAHE:  PR  I NT_L I  HE 
AUTHOR:  S.  Treaduiell 
CREATED:  13  APR  92 
UPDATED:  28  OCT  92 

Used  for  debugging  purposes.  (Jill  print  out  whateuer  line  of  code  has  been 
most  recently  stored  in  the  this_line  buffer. 


uo i d  pr i nt_l i ne( t h i s_l i ne , out  f i I e ) 

struct  I i s t _ info  *t  h  <  3 _ line; 

FILE  *out  f I le; 

( 

i  nt  i  ; 

for  (i  =  0;  i  <  th i s_l i ne->l ength;  +♦ i  ) 

fpr  i  nt  f  (out  fi  le,  "Jls  “ ,  th  i  s_l  ine->entry[  i  J.name); 
i f(this_l ine->length  >  0)  fpr i nt f ( out f i 1 e , "\n " ) ; 
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/* - - - - - - - 

CALLNAflE:  TARGET_FOUND 
AUTHOR:  S.  Treadwell 
CREATED:  29  JUL  92 
UPDATEO:  29  JUL  92 

Used  in  parsing  loop  statements.  Helpful  in  distinguishing  between  a  for_ 
loop  and  a  uthile—loop  since  loops  are  keyed  on  the  word  "loop"  and  not  on 
"for"  or  "while."  The  boundary  string  is  used  to  bound  the  search  for  the 
beginning  of  the  loop,  lie  don't  want  to  search  infinitely  and  possibly  find 
a  loop  beginning  that  does  not  apply  to  the  giuen  loop.  Consider  the 
fo I  lowing  examp  I e : 
for  i  i n  1 . . 1 0  J  oop 
I  oop 

end  loop; 
end  loop; 

lihen  parsing  the  inner  loop  construct,  we  don't  want  to  find  the  beginning 
of  the  outer  loop  and  mistakenly  identify  a  basic  loop  as  a  for,  ,  loop. 
_ *  / 


enum  boolean  target_found( th i s_l i ne , target , boundary ) 
struct  list— info  *this_ line; 
char  target[]; 
char  boundary[]; 

{ 

int  i ,k; 

enum  boolean  success  =  NO; 

/*  Start  at  the  word  “loop"  and  search  backwards  for  the  target  without  */ 
/*  going  further  back  than  allowed  by  the  boundary  set.  */ 

for(i  =  this-l ine->marker  -  1;  i  >=  0 ;  — i) 

{ 

if((k  »  st rcmp( th i 3_l i ne->ent ry[ i ]. name , target ) )  =  =  0) 

{ 

success  =  VES; 

th i s_ I ine->marker  =  i; 

break ; 

} 

if((k  *  st rcmp( t h i s—l i ne- >ent ryC i ]. name , boundary ) )  ==  0) 
break ; 

> 

/*  The  success  integer  indicates  whether  the  target  was  found  */ 
return(success) ; 
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CALLNAnE :  EURE _ RANGE_NUfl 

AUTHOR:  S.  Treadwell 
CREATED:  5  MAV  92 
UPDATED:  15  JUN  92 

Uill  take  a  string  expression  for  a  range  like  ’O.^O'  and  parse  it  into  a 
first,  last,  and  span  values.  These  values  are  then  stored  in  the  data 
structure  'ailed  range,  and  the  span  value  is  also  returned  os  the  output  of 
the  funct I  on . 

- - - - - - - »/ 


int  eva l_range_num(word, error_f i le) 
char  uiordf]; 

( 

int  evaluateO; 

int  eva l_s imp  I e_num( ) ; 

int  eva l_natura l_num( ) ; 

int  eval_complex_num()  ; 

i  "it  c; 

int  i  *  0; 

int  j  =  0; 

char  min[20]; 

char  max[20]; 

struct  range_info  temprange; 

st rcpy ( t emprange . descr i pt i on , ward ) ; 

/*  find  the  first  value  in  the  range  V 
wh  i  I  e(  i  sa  I  num(c  =  uiordf  i])) 
mint i ♦♦ D  ■  c; 
mint i J  *  ‘ \0 ’ ; 

++  i ; 

/*  find  the  last  value  in  the  range  */ 
uihi  I e ( isalnunfc  *  uiordt  i ♦♦]) ) 
max[  j ♦♦]  =  c; 
ma x C j  ]  =  ’NO’ ; 

/*  evaluate  the  first  value  in  the  range  */ 
switch(evaluate(min)j 
{ 

case  SlflPLENUfl:  temprange , f i r3t  =  eva I _s i mp I e_num( m i n) ;  break; 
case  NATURALNUtl:  t emprange . f i rst  =  eva l_natura l_num( m i n ) ;  break; 
case  COhPLEXNUH:  t emprange . f i rst  =  eva l_comp I ex_num( m i n ) ;  break ; 
case  UARHADE :  temprange . f i rst  =  LOST;  break; 
case  UNKNOUN:  temprange  ,  f i rst  =  LOST;  break; 
default:  temprange  ,  f i rst  =  LOST;  break; 

} 

/*  evaluate  the  lost  value  in  the  range  */ 
switch (evaluate (max)) 

{ 

case  S I  (1PLEHUH :  t emprange . I ast  =  eva I _s i mp I e_num(mox ) ;  break; 
case  NATURALNUH:  t emprange . I ast  =  eva l_nat ura l_num(mox ) ;  break, 
case  COHPLEXHUH :  temprange . last  =  eva l_comp I ex_num(max ) ;  break; 
case  UARHAI1E  :  t emprange . I ast  =  LOST;  break; 
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case  UNKNOUN:  temprange . I ast  =  LOST;  break; 
default;  temprange . I ast  =  LOST;  break ; 

> 

/*  calculate  the  range  */ 

i f ((temprange . f irst  1=  LOST)  S.8.  (temprange , I ast  !  *  LOST)) 
temprange. span  =  temprange . I ast  -  temprange . f i rst  +1; 

e  I  se 

temprange . span  =  LOST; 
ret urn (temprange . span) ; 

) 


CALLNAflE:  EUAI _ NRTURAI _ HU n 

AUTHOR;  S.  Treadwell 
CREflTEO:  4  flflV  92 
UPDATED:  15  JUM  92 

Hill  take  an  expression  like  '  natura I (number )  '  and  eualuate  its  ualue  based 
upon  the  number  within  the  parentheses.  This  ualue  is  then  returned  os  the 
ualue  of  the  expression. 


int  eua I _nat ura l_num( word ) 
char  word[40j; 

{ 

int  eualuateO; 

int  eua l_s imp  I e_num( ) ; 

int  eua l_comp I ex_num( ) ; 

int  c; 

int  i  -  0; 

int  j  *  0; 

int  ualue  =  LOST; 

char  argument[40] ; 

i f  ( word [ 7 ]  *=  '  (  '  ) 

{ 

i  =  8; 

while((c  =  word[i++])  !=  ’)') 
argument [j ++ ]  =  c; 
argument [ j ]  =  ’ \0  '  ; 
sw i t ch(eua I uate( argument)) 

{ 

case  SmPLENUtt;  ualue  =  eua  l  _s  i  mp  I  e_num(ar  gument ) ;  breok; 
case  COflPLEXHUII;  ualue  =  eua  I  _comp  I  ex_num(  orgument ) ;  break; 
case  UARNRHE :  ualue  -  LOST;  breok; 
case  UNKNOUN ;  ualue  =  LOST;  break; 
default:  ualue  =  LOST;  breok; 

) 

) 

return(ua I ue) ; 

} 
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CALLNRRE:  EUAL_CORPLEX_NUR 
AUTHOR :  S ,  Treadwe  1 1 
CREATED:  1  RAY  92 
UPOATED:  15  JUN  92 

Uill  take  a  string  expression  like  ,!6*ffff*'  and  parse  it  into  a  singlt 
integer  value  and  return  that  value  as  the  output  of  the  function. 

The  string  must  be  in  o  form  aimost  exactly  like  that  given.  Any  base  or 
internal  value  can  be  used,  provided  that  it  is  not  too  large  to  be  held 
in  an  integer. 


int  eva l_eomp I ex_num(uord) 
char  word[]; 

< 

int  i  ■  0; 
int  j  *  0; 
int  c; 

int  baseualue; 
int  numualue  =  LOST; 
char  bose[20]; 
char  num[20]; 

«ih  i  I  e(  i  sd  i  gi  t  (c  »  iuord[i])) 
base [ i +  +  ]  *  c ; 
base[ i +  +  ]  *  * \0 ' ; 

ujh  i  I  e(  i  sxd  ig  i  t  <  c  =  uiord[i+  +  ])) 
num[  j  ♦♦]  =  c; 
num[ j ]  »  ' \0 ‘ ; 

basevalue  =  strt o I (base , ( char  *  * ) MULL ,10); 
numualue  =  strto I (num, (char  **)HULL, baseva lue) ; 

return(numvalue) ; 

) 

/* - - - 

CALLNARE:  EUAI _ S I RPLE_NUR 

AUTHOR:  S.  Treadwell 
CREATED:  1  RAY  92 
UPDATED:  5  RAY  92 

Uill  take  a  pure  number  in  string  form  and  convert  it  to  integer  form  and 
return  that  integer  as  the  output  of  the  function. 

Cannot  deal  rnith  floating  point  numbers;  only  integers  are  ol loved. 

Assumes  that  everything  expressed  as  a  pure  number  is  in  base  10. 

- - - - - . V 


int  eva l_s i mp I e_num( word ) 
chor  uiord[]; 

{ 

int  value  *  LOST ; 

value  =  strtol (word, (char  **)NULL,I0); 
ret  urn( vo lue); 
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/* . . . . . 

CALLNAME :  EUAIUATE 
AUTHOR :  S.  Treadwell 
CREATED:  1  MAY  92 
UPDATED:  5  MAY  92 

Uill  take  a  string  as  ar  input  argument,  eualuate  the  contents  of  that  string 
and  put  it  in  a  class  according  to  its  configuration.  The  class  is  returned 
as  an  integer  ualue  and  the  classes  are  defined  in  “header, h“ 

Works  for  all  tested  cases,  but  may  not  be  foolproof.  A  safety  net  is 
prouided  through  the  UNKNOUN  class  of  string,  which  is  triggered  when  the 
string  does  not  fit  any  of  the  allowed  patterns. 

- - - - - */ 

int  eualuate(word) 
char  word!]; 

( 

int  class  =  UNKNOUN; 
int  i  ■  0; 
int  k  «  0; 
int  c; 

int  dots  =  0; 
int  pound  ■  0; 
int  other  =  0; 

if  ( i sd i g i t ( word! 0] ) ) 

{ 

while((c  =  word[i++])  !=  ' \0 1 ) 

{ 

i f (c  ■■  '  . ' )  +*dot s ; 
i f (c  ■■  1  * ' )  ++pound; 
i f ( ! isdigi t (c) )  ++other; 

} 

if  ((dots  ==  2)  8.  (pound  ■*  0)  8.  (other  ==  2))  class  =  RANGENUM; 

if  ((dots  —  0)  8  (pound  ==  2)  &  (other  >=  2))  class  «  COnPLEXNUri; 

if  ((dots  ==  0)  8  (pound  ==  0)  8  (other  ==  0))  class  =  S I MPLENUM ; 


if  ( i sa I pha( word[ 0] ) ) 

{ 

class  *  UARNAME; 

if((k  *  strncmp( word , "nature  I " , 7) )  *■  0)  class  =  NRTURALNUM; 
while((c  *  word[i++])  !=  '\0') 
i f (c  ■■  ' . ' ) 

if((c  c  word[i++])  =*  '.')  class  =  RANGENUM; 

} 

return(c I oss) ; 

) 
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/* - - 

CALLNAflE :  PR  I NT_PROCEDURES 
AUTHOR :  S.  Treaduell 
CREATED:  19  OCT  92 
UPDATED:  19  OCT  92 

Uili  print  out  the  models  for  each  of  the  procedures  found  for  a  given  task 
This  procedure  is  provided  for  filling  the  error  lag  uilth  valuable  info  for 
tracking  domn  analysis  and/or  run-time  errors. 

. - . — . —  »/ 


void  pr i nt_procedures( procedures, error_f i I e) 
struct  proc_l ist_info  *procedures; 

FILE  *error_f i le; 

( 

int  i,j,k; 

f or( i  *  0;  i  <  procedures- > I ength;  ++I) 

{ 

fpr i nt f (error_f i I e , “Procedure  ts  found  in  Jts\n“ , procedures- >entry[ i ]. name , 
procedures- >entry[ i ] . f i I ename) ; 
for(j  *  0;  j  <  procedures- >entry[ i ]. ske I et on , I ength;  +  +  j  ) 

fpr i nt f ( error_f i I e,  "Type : X3d  Uolue:X4d  Depth:X3d  Po i nter : X3d\n“ , 
procedure s- >entryt i ] . skeleton. entrytj]. type, 
procedures- >entry[ i ] .skeleton. entrytj ] .value, 
procedures- >entry [ i ] . ske leton. entrytj ] .depth, 
procedures- >entry[ i ] . ske leton. entrytj 1 .pointer); 
for(j  =>  0;  j  <  procedures- >entry[ i j . ske I et on . num_count ers;  *+j ) 

fpr  i  nt  f  (error_f  i  !  e,  "Ctr  X2d-.  Queued  X3d  Rtrvd  X3d  Sent  X3d  Read  %3d\n",j, 
procedures->entryf i ] . skeleton. counter_set [ j ] . num_queued, 
procedures->entry[ i ] . ske ! eton . count er_set [ j ] . num_retr i eved, 
procedures- >entry[i].skeleton. count er_set [ j ] . num_sent , 
procedures- >entry[ i ] . ske I et on . count er_set [ j ] . num_read ) ; 

) 

> 

void  c I ear_screen( ) 

{ 

pr int  f ( "\033tXdJ" , 2) ; 

pr int  f ( " \n" ) ; 

> 
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/* - - - - - 

CALINAOE :  F I HD_UORST_PATH 
AUTHOR:  S.  Treadwell 
CRERTEO :  01  SEP  92 
UPOATEO:  20  OCT  92 

For  a  given  model,  this  procedure  controls  model  preparation,  reduction,  and 
path  generation.  The  execution  path  generation  leads  to  identification  of 
the  morst  case  path  and  the  parameter i zat i an  of  that  path  is  returned  to  the 
parent  procedure,  process-list. 

- - - — . - - - - - */ 


struct  counter_l i st  f  i  nd_«iorst_ path(  ske  I  et  on,  de  I  oy_dat  a,  error_f  i le) 
struct  model-info  ‘skeleton; 
struct  constant-list  ‘delay_data; 

F I LE  ‘error— f i I e; 

( 

void  reduce_mode I ( ) ; 

int  ca I cu I  at e_ t i me() ; 

enum  boolean  model— ok(); 

struct  counter— list  generate— pothsO ; 

struct  counter— list  big_counter,  new_count er ; 

int  i ; 

/*  Initialize  path  paramet er i zat i on  */ 
b i g-counter . num_ queued  =  0; 
b i g_ counter . num_ retr i eued  =  0; 
b i g_counter . num-sent  =  0; 
b i g-counter . num_ read  ■  0; 
big_counter.total_t ime  =  0; 
b i g_ count  er . num_ msg_ queued  =  0; 

/*  prepare  and  reduce  the  model  */ 

reduce— mode  I <  ske I eton , de I ay_data , error_f i I e) ; 

/♦  include  the  final  task  model  in  the  error  log  */ 
fpr i nt  f (error— f i I e , "Task  hode I . . . \n" ) ; 
for(i  *  0;  i  <  ske I et on->  I  ength;  ♦♦i) 

fpr i nt f (error— f i I e , “*3d  Type:X3d  Uolue:X1d  Depth:X3d  Po i nt er : X3d\n“ ,  i  , 
skelet on- >e nt ry [i], type, ske let  on- >ent ry [ i ] . value, 
ske  I  eton- >ent  ry[i], depth, skeleton->entry[i). pointer); 
for( i  =  0;  i  <  skeleton- >num_counters;  +  +i) 

fpr int f (error_f i le, “Ctr  X2d:  Queued  X3d  Retvd  X3d  Sent  X3d  Read  %3d\n“ , 
i , ske I eton->counter_sel [ i ] . num_queued, 
ske I et on- >count er_ set [ i ] . num_ retr i eued, 
ske I eton->count er— set [ i ] . num_ sent , 
ske I et on->count  er_set [ i ] . num-read) ; 

i f ( mode  I _ ok( ske I et on , error— f i I e ) )  /*  trap  for  model  errors  */ 

< 

/*  generate  .'II  possible  paths  that  start  ot  the  top  of  the  model  */ 
b i g_ count er  *  generat e_pat hs( ske I et on , de I ay_dat o ,0,2, error_f i I e ) ; 

/*  generate  paths  beginning  with  each  UFS  entry  in  the  model  */ 
for(i  »  0;  i  <  ske I et on- >1 engt h ;  ++i) 
i f(skeleton->entry[ i ] .type  ==  UFS) 

{ 

new_counter  =  generat  e_pat hs (ske I et  on, de I ay_dat  o, i  +  l , 2, error- f i le), 
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if  (calculated iffle(delay_data,&nem_counter)  > 
ca I cul a  ted i me(de I ay_dat a ,  8.b i g_count  er ) ) 
big_counter  =  new_counter; 

} 

} 

else  fpr  i nt  f  (errord i  I e,  "The  model  could  not  be  processed  due  to  faultsW); 
return(b i g_counter ) ; 

) 

/* . . . . . . 

CALLNAflE :  REDUCEdlQOEl 
AUTHOR:  S.  Treadue I  I 
CREATED:  06  OCT  92 
UPDATED:  19  OCT  92 

This  procedure  takes  a  giuen  model  and  completes  it's  development.  It  then 
reduces  it  by  squeezing  out  loops,  if's,  and  case  statements  that  hove  no 
UFS  inside.  These  constructs  are  replaced  by  counter_3et  entries. 
- - V 


uo i d  reduce_mode I (skeleton, del ay_dat a, error_f i I e ) 
struct  model_info  *skeleton; 
struct  const ant_l i st  *delay_dota; 

F I LE  *error_f i I e; 

{ 

void  crunchO; 
void  check_ctrs( ) ; 
uo i d  nest_l eue I  ( ) ; 
uoid  match_l oops( ) ; 
i  nt  i ; 

/*  model  preparation  */ 
nest _ I eue l (skel eton) ; 
mat ch_ I  oops (skeleton); 

/*  for(i  ■  0;  i  <  ske I et on- > I engt h ;  ++i) 

fpr  i  nt  f  (errord  i  I  e,  “  X3d  Type:*3d  Ualue:X1d  Depth:X3d  Po i nter : *3d\n" , i  , 
ske  I  eton->entry[ i ] . type, ske I et on->entry [ i ] . ual ue, 
skeleton- >entry[ i ] . depth, skeleton->entry[i]. pointer);/**/ 

/*  model  reduction  */ 

crunch ( ske I et  on, de I ay_dat a, LOOP , error_f i I e) ; 
crunch (ske I eton,  del  ay— dot  a, UH I LEdOOP, error— f i le) ; 
crunch (ske I eton, de I ay_data, F0R_L00P, error_f i I e ) ; 
crunch(skeleton,delay_data, !F,error_f i le); 
crunch (ske I eton, de I ay_dat a, CASE , error_f i I e ) ; 

/*  eliminate  any  empty  counter_set  entries  */ 
check_ctrs(ske I et on, error_f i I e) ; 

} 
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CALLNAflE :  NEST_LEUEL 
AUTHOR:  S.  Treadwell 
CREATED:  0?  AUG  92 
UPDATED:  01  flAR  93 

Takes  the  abstracted  model  and  determines  the  level  of  nesting  for  each  item 
in  the  model.  This  is  necessary  for  the  process  of  matching  loops  and  other 
control  flow  items.  Each  type  of  model  entry  has  a  particular  effect  on  the 
nesting  value  for  entries  that  follow. 

- - - »/ 


void  nest_l eve  I (ske I eton) 
struct  model-info  ‘skeleton; 

{ 

int  i ; 

int  nest  “  0; 

for  ( i  »  0;  i  <  ske I et on-> I engt h;  ♦♦  i ) 
swi tch(ske leton->entry[ i ] . type) 

{ 

case  LOOP: 

ske leton->entry[ i ]. depth  =  nest; 

♦♦nest ; 

break; 

case  F0R_L00P: 

skeleton->entry[ i ] .depth  =  nest; 

♦♦nest ; 

break; 

case  WHILE-LOOP: 

skeleton->entry[ i ] .depth  =  nest; 
♦♦nest ; 
break; 
case  IF: 

ske I eton->entry[ i ] . depth  =  nest; 
♦♦nest ; 
break ; 
case  ELSIF: 

--nest ; 

ske I et on- >ent ry[ i ] . depth  =  nest; 
♦♦nest ; 
break; 
case  CASE: 

ske I eton- >entry[ i ], depth  =  nest; 
♦♦nest ; 
break ; 
case  UHEN: 

— nest ; 

skeleton->entry[ i ] .depth  =  nest; 
♦♦nest ; 
break ; 
case  ELSE: 

— nest ; 

ske I et on->entry[ i ] . dept h  =  nest; 

♦♦nest ; 

break; 

case  EH0-L00P: 

--nest ; 
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ske I eton- >ent ry[ i  ] . depth  «  nest; 
break; 

case  EMD _ I F : 

— nest ; 

ske leton->entry[ i ]. depth  »  nest; 
break; 

case  EN0_CflSE: 

— nest ; 

ske leton->entry[ i ]. depth  =  nest; 
break; 
default : 

ske I eton->entry[ i ] , depth  =  nest; 

> 
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/* - - - - - - 

CALLNAHE :  f1ATCH_L00PS 
AUTHOR:  S.  Treadwell 
CREATED:  0?  AUG  92 
UPDATED:  01  HAR  93 

This  procedure  will  look  through  the  model  and  match  loop  statements  with 
the  proper  end_loop  statements.  Likewise  for  the  if  end_i f  and  case 
end_case  pairs,  Other  matchings  are  necessary  as  well.  Note  that  empty 
loops  are  eliminated  in  the  beginning.  It  may  be  necessary  to  do  the  same 
with  empty  if's  and  empty  case  statements.  The  matching  is  accomplished 
through  the  establishment  of  the  pointer  elements  in  model  entries. 
- - - */ 


uoid  match_loops(skeleton) 
struct  model_info  ♦skeleton; 

{ 

int  loop_starts[20]; 
int  num_loops  *  0; 
int  i,j; 

for  (i  *  0;  i  <  ske I et on- > I engt h;  ++i) 
skeleton->entry[i3  pointer  =  UNDEFINED; 

/*  Eliminate  empty  loops  */ 
for  (i  =  0;  i  <  ske I et on- > 1 engt h ;  ++i) 
sw i tch(ske I et on- >ent ry [ i ] . t ype) 

{ 

case  FOR_LOOP: 

i f (ske I et on- >ent ry [ i  + 1  ] . t ype  ==  EN0_L00P) 

{ 

for(j  =  i;  j  <  ske  I  eton-> I ength  -  2;  ++j  ) 
skeleton->entry[ j ]  =  ske I et on- >ent ry [ j +2] ; 
ske  I  et on- > I engt h  -=  2; 

> 

break; 

case  UH I IE_L00P : 

i f (3ke I et an- >ent ry [ i + I ] . t ype  =  =  END_l00P) 

( 

f  or  ( j  =  i;  j  <  skeleton-Mength  -  2;  +  +  j  ) 
ske  I  et on- >ent ry [ j ]  =  ske I e t on- >ent ry [ j +23 ; 
ske I et on- > I engt h  -=  2; 

} 

break; 

default :  break ; 

} 


/*  loop_starts  is  an  array  of  index  ualues  for  entries  that  represent  */ 
/*  the  beginning  of  a  loop  construct.  it  simplifies  the  matching  of  */ 
/*  loop  starts  and  end_!oop  entries.  */ 

for  (i  =  0;  i  <  ske I et on- > I engt h ;  ++i) 
switch (ske leton->entry[ i 3  type) 

( 

case  LOOP:  loop_starts[num_loops++]  =  i;  break; 
case  F0R_L0QP:  I oop_starts(num_l oops++ 3  =  i;  break; 

case  U H I L E _ L OOP:  I aop_st art s[num_l oops  +  + ]  =  i;  break; 

case  EN0J.00P: 

ske I et on- >ent ry[ i 3 . po i nt er  *  I oop_star t s[ --num_l oops 3 ; 
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ske I et on->entry [ ske I eton- >ent  ry[ i ]. po i nter] . po i nter  =  i ; 
break ; 

case  EHD—IF:  /*  match  with  the  corresponding  IF  statement  */ 
for(j  =  i -t ;  j  >=  0;  --j ) 
i  f{(skeleton->entry[j  ]  .type  ==  I F >8,8. 

(ske I et on->ent ry [ j ] . dept h  **  ske I et on- >ent ry [ i ] . dept h) ) 

( 

ske leton->entry[ j ] .pointer  =  i; 
ske I eton->ent ry [ i ] . po i nt er  -  j ; 
break ; 

} 

break; 

case  END_CAS£:  /*  match  with  the  corresponding  CASE  entry  */ 
f  or  ( j  «  i-1 ;  j  >-  0;  —j  ) 
i  f((skeleton->entry[j ] .type  ==  CASE)8.8, 

(skeleton->entry[j ] .depth  ==  ske I et on- >ent ry [ i ] , dept h ) ) 

{ 

skel eton->entry[ j ] .pointer  =  i; 
ske I et on->ent ry [ i ] . po i nt er  =  j; 
break ; 

} 

break ; 

case  UHEN:  /*  point  to  next  UHEM  or  EN0_CASE  entry  */ 
for(j  =  i ♦ 1 ;  j  <  ske ! eton-> I ength;  +  +  j) 
i f ( ( (ske I et on- >entry [ j ] . type  ==  UHEN)|| 

(ske  I  eton- >entry  [  j  ] .  type  ==  END_CASE))  &8. 

( ske I et on->ent ry [ j ] . dept h  ==  ske I et on- >ent ry [ i ]  .  dept h )  ) 

{ 

ske  I  et  on->er>t  ry  [  i  ]  .  po  i  nt  er  =  j; 
break; 

} 

break ; 

case  IF:  /*  point  to  next  branch  in  the  “if“  construct  */ 
f  or ( j  =  i ♦ 1 ;  j  <  ske I eton->  I  engt h;  ) 
i f ( ( (ske I et on- >entry[ j ] . t ype  ==  ELSE ) I  I 
(ske I et an- >ent ry [ j ] . t ype  ==  ELS  i  F  )  I  I 
(ske  I  et  on- >ent  ry  [  j  ]  .  t  ype  ==  END_IF))  8.8. 

( ske I et on->ent ry [ j ] . dept h  ==  skel eton- >entry[ i ]. dept h ) ) 

{ 

skeleton->entry[ i ] .pointer  =  j; 
break ; 

} 

break ; 

case  ELS  I F :  /*  point  to  next  branch  in  the  "if"  construct  */ 

for(j  =  i  +  1;  j  <  ske I eton- > I engt h ;  +  +  j  ) 
i  f((  (ske  letor.- >entry[j  ].  type  ==  ELSE  )  I  I 
(skeleton->entry[j ] . type  ==  EL  S  I F )  I  I 
(ske  leton->entry[  j  ].  type  ==  E  ND_  IF))  8.8, 

(ske I et on->ent ry [ ] ] , dept h  ==  ske I et on- >ent ry [ i ] . dept h  )  ) 

( 

ske I et an->ent ry [ i ] . po i nt er  =  j; 
break ; 

} 

break; 

case  ELSE:  /*  point  to  the  end  of  the  "if"  construct  */ 
for(j  *  i+1;  j  <  ske I et on- > I engt h;  ++j) 

i  f  ( ( ske  I  et  on- >ent  ry  [  j  ]  .  t  ype  ==  E  ND _ I  F )  8.8. 

(ske I et on->ent ry [ j ] . dept h  ==  ske I et on- >entry [ i  ] . dept h ) ) 

{ 
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akeleton->entry[ i ] .pointer  *  j; 
break; 

) 

break ; 

default:  break; 

) 


/* - - - 

CALLNAtlE :  CRUNCH 
RUTHOR:  S.  Treadwell 
CREATED:  01  SEP  92 
UPDATED:  19  OCT  92 

This  procedure  identifies  constructs  that  do  not  contain  IIFS  colls  and 
crunch-3  them  into  a  set  of  counters  to  replace  the  construct.  This  is 
necessary  simplification  because  it  allows  loops  that  contain  critical 
constructs  to  be  counted  for  their  total  iterations,  not  just  a  single 
pass  through. 

— - - - - */ 


uoid  crunch( ske I eton, de I ay_dat a , st art_t ype , error_f i le) 

int  start_type; 

struct  model. info  ‘skeleton; 

struct  const ant_l i st  *delay_data; 

F ILE  *error_f i le; 

{ 

struct  counter.list  generate_paths( ) ; 

Struct  model.info  temp; 

int  i,j; 

int  k  *  0; 

int  begin; 

int  end; 

enum  boolean  present  =  NO; 
enum  boolean  qualified  =  NO; 

for(i  =  0;  i  <  ske leton->l ength;  ++i) 

( 

/*  Guard  against  crunching  loops  with  undefined  iteration  moximums  */ 
qua  I i f i ed  *  NO; 

i f(skeleton->entry[ i ] . type  •=  start.type) 
sw i tch(start_type) 

{ 

case  IF:  qualified  =  VES;  break; 
case  CASE:  qualified  =  VES;  break; 

default:  i f ( ske I et on->ent ry [ i ] . uo  I  ue  >  0)  qualified  =  VES;  break; 

} 


/*  Find  the  bounds  on  the  targeted  construct  */ 
i f  (qua  I i f i ed  *=  VES) 

( 

begin  »  i ; 

for(j  =  i  ♦ 1 ;  j  <  ske  I  eton-> I ength;  ♦  +  j ) 

{ 

i f (ske I et on->ent ry [ j ] . t ype  =  =  UFS)  present  =  VES; 
i f(skeleton->entry[j ] .pointer  ==  begin) 

( 


175 


Appendix  D 


end  *  j ; 
break ; 

} 

} 

if(lpresent)  /*  if  no  UF S  entry  within  the  construct  */ 

{ 

/*  set  up  the  temporary  model  for  the  targeted  construct  */ 
for(j  »  begin;  j  <=  end;  ++j ) 

{ 

temp ,entry[k]  =  skel eton->entry[ j  ]; 
temp. entrytk] .pointer  -  =  begin; 

♦  ♦k; 

) 

temp  .  I ength  =  k; 

ske I et on- >ent ry [beg i n] . t ype  =  COUNTERSET ; 

skeleton->entry[begin] .pointer  =  UNDEFINED; 

ske I et on->entry[beg i n] . ua  I  ue  =  ske I eton- >num_count ers; 

/*  establish  the  worst  path  parameter i zat i on  for  the  temporary  model  */ 
/*  and  use  it  as  a  counter_set  entry  in  the  model  to  replace  the  */ 
/*  targeted  construct  */ 

ske I et  on- >count  er_set [skeleton- >num_counter s++ ]  = 
generat e_pat hs(&t emp , de I ay_dat a, 0,1,  error_f  i  I  e) ; 

/*  Adjust  the  original  model  to  compensate  for  eliminated  entries  */ 
for(j  =  begin  ♦  I;  j  <  ske I eton- > I ength  -  <  k  —  1 ) ;  +»j  ) 
skel eton->entry[ j ]  =  ske I et on- >ent ry [ j ♦ ( k- 1 ) ] ; 
f or ( j  ”  0;  j  <  ske  I  eton->l ength  -  <  k - 1 ) ;  ♦♦]) 
if  (skeleton->entry[j ] .pointer  >=  begin) 
ekeleton->entry[j ] .pointer  -=  (k-1); 
ske I et on- > I engt h  -=  (k-l); 
k  =  0; 

} 

else  present  =  NO; 

) 

> 

} 
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> 


/* - - - 

CALLNAI1E :  CHECK_CTRS 
AUTHOR :  S  .  Treoduie  I  I 
CREATED;  16  NOU  92 
UPDATED;  16  NOU  92 

Uill  examine  the  skeleton  sent  in  and  check  for  COUNTER_SET  entries 
containing  only  zeros,  These  is  i  I  I  be  remoued  from  the  model. 

- - - v 

void  check_ctrs(ske I eton, error_f i le) 
struct  model_infa  ’skeleton; 

F I LE  *error_f i le; 

{ 

int  i.j,k; 
int  sum; 

for( i  1  ske I et on- >num_counters  -  I;  i  >=  0;  — i) 

{ 

sum  »  0; 

sum  =  ske I et on- >count er_set [ i ] . num_queued  ♦ 
ske I et  on- >count  er_se t [ i ] . num_ret  r i eued  ♦ 
ske I et  on- >count  er_set [ i ] . num_sen t  ♦ 
ske I et  on- >count  er_se t [ i ] . num_read ; 

if(sum  **  0)  /*  eliminate  the  entry  and  adjust  the  model  accordingly  */ 

( 

--ske I et  on- >num_count  ers ; 
for(j  *  i;  j  <  ske I et on- >num_count ers ;  ♦*j  > 
ske I et on- >count er_set [ j ]  =  ske I et on- >count er_  set [ j ♦  I  ] ; 
for(j  -  0;  j  <  ske I  ton- > I engt h;  +*j  ) 
i f ( ( ske I et on- >ent ry [ j ] . t ype  **  COUNTERSET)8,8. 

( ske I et on->ent ry [ j ] , ua I ue  **  i  ) ) 

{ 

--ske I et on- > I engt h ; 

for(k  *  j;  k  <  ske I e t on- > I engt h ;  ♦♦k) 

ske I e t on- >en t ry [ k  ]  *  ske I e t on- >ent ry [ k* 1  ] ; 

) 

for(j  =  0;  j  <  ske I e t on- > I  eng t h;  ♦♦j  ) 
i  f((skeleton->entry[j  ]  .type  **  COUNTERSET  )8.& 

( ske I e t on- >en t ry [ j ] . va I ue  >  i)) 
ske I et on- >ent ry [ j 3 . oa I ue  --  1; 

) 

> 

) 


» 


> 


» 


» 


» 


» 


> 


» 
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/*- . — . — - - 

CfiLLNRflE ;  GENERATE.PATHS 
AUTHOR:  S.  Treadwell 
CREATED:  15  AUG  92 
UPDATED :  19  OCT  92 

This  procedure  generates  all  possible  execution  paths  through  a  giuen  model. 
It  begins  at  the  designated  starting  entry  and  exhausts  all  paths  from  that 
point  using  the  decision  integer  as  the  path  determinotor .  Once  a  path  is 
defined,  it  is  parameter i zed ,  quantified,  and  compared  to  preuious  paths. 

- - - - - - - - */ 

struct  counter_l ist  generat e_pat hs(ske I et on, de I ay_dat a, st art , mode , error_f i le) 

struct  model.info  *skeleton; 

struct  constant.! i st  *delay_data; 

int  start; 

int  mode; 

FILE  *error_f i ie, 

{ 

int  ca I cu I ate_t i me( ) ; 
int  decideO; 

struct  counter.list  parameter i ze( ) ; 

struct  counter.list  d i g.counter , new.count er ; 

int  path[30]; 

int  j  =  0; 

int  i ,k; 

int  done; 

int  next; 

int  shift_num; 

unsigned  long  temp; 

unsigned  long  decision  *  0x00000000; 

b i g.count er . num_queued  =  0; 
b i g.count er . num.ret r i eued  =  0; 
b i g.count er . num.sent  =  0; 
big.counter ,num_read  =  0; 
b i g.counter . num_msg_queued  =  0; 
b i g.count er . t ot a  I _t  i  me  =  0; 

uih i I e( dec i s i on  <  0x80000000)  /‘dec i s i on=80000000  means  all  paths  exhausted*/ 

{ 

for(i  =  0;  i  <  ske I eton-> I ength ;  ♦♦i) 
ske  I  etan- >ent ryt i ] . f I otti  =  BLANK; 
i  =  start;  shift_num  =  30;  done  =  NO; 
do 
{ 

if  ((mode  ==  I)  8,8,  (i  ==  ske  I  et  on- >  I  engt  h  -  1))  done  =  VES, 

switch(skeleton->entry[  i  ]  .  floui) 

< 

case  EXEC:  next  *  i  ♦  1 ;  path[ j ♦♦]  =  i;  break; 
case  N0.EXEC:  next  =  i  ♦  I;  break; 
defaul  t : 

pothfj]  ■  i;  /*  printfC’i  is  Xd\n" ,  i  ) ; /**/ 
suiitch(skeleton->entry[  i  ]  type) 

( 

case  UH I LE_L00P : 

next  =  dec  i  de( ske I et on , i , 8 j , dec i s i on  &shift_num); 
break; 
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case  END-LOOP: 

i f (mode  "  I )  next  =  i  ♦  1 ; 

else 

( 

i f (ske I eton- >ent ry [ ske let on ->entry[i]. pointer]. value  ==  INFINITE) 

{ 

next  •  skel eton->entry[ i ] .pointer; 

**i  i 

) 

else  next  =  dec i de( sk e I eton , i ,8 j , dec  I s i on ,8sh i f t_ num ) ; 

) 

break ; 
case  IF: 

next  ”  dec i de( ske I et on, i ,8 j , dec i s i on ,8sh i f t_ num) ; 
break; 
case  ELSE: 

next  =  i  +  1 ; 

++ji 

break; 
case  ELSIF: 

next  =  dec i de( ske I et on, i , 8 j , dec i s i on ,8sh i f t_num ) ; 
break; 
case  UHEN: 

next  =  dec i de  ( ske I et on , i , 8 j , dec i 3 i on ,8sh i f t_ num ) ; 
break ; 
case  UFS: 

**\ ; 

done  *  VES; 
break ; 
default : 

**} ; 

next  *  i  +  I  ; 
break; 

} 

break; 

> 

i  =  next ; 

} 

«ih  i  I  e(  !  done)  ; 

if(mode  ==  2)  /*  mode  2  is  for  full  task  model  analysis  */ 

{ 

fprintf(error_fi I e , "PATH : " ) ; 
for( i  *0;  I  <  j  ;  ♦  ♦  i  ) 
fprintf(error_fi 1 e , " X3d“ , pat h[ i ]); 
fprintf(error_fi le, "\n"); 

) 

/*  parameterize  the  path  just  completed  and  compare  to  prev.ous  paths  * 
new_ counter  =  poramet er i ze ( ske I et on , pat h , j , mode  ) ; 
i  f  tea  I  cu  I  at  e_t  i  me( de  I  ay_dat  a ,  8ne«i_ count  er )  > 
ca I cu I  at  e_t i me( de I ay_dat  a ,  8b  i g_count  er ) ) 
big_counter  =  neuj-counter; 
j  0; 

♦♦shift— num;  /*  a  necessary  adjustment  */ 

/*  now  update  the  decision  integer  to  determine  the  next  path  */ 

/*  the  math  here  effectively  reverses  the  lost  decision  mode  */ 

/*  in  the  lost  execution  path  */ 

decision  8=  (Oxffffffff  '<  shift_num); 
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decision  (0x01  <<  shift_num); 

} 

/*  big_counter  is  the  parameter i zat i on  of  the  worst  case  path  through  */ 
/*  the  giuen  model  for  the  gioen  starting  point  */ 

ret urn (b i g_counter ) ; 


/* - 

CflLLNflilE :  DECIDE 
AUTHOR :  S.  Treadwell 
CREATED:  16  AUG  92 
UPDATED:  15  SEP  92 

This  procedure  makes  the  decision  of  where  to  go  next  according  to  the 
decision  integer.  The  next  point  in  the  path  is  returned  os  an  integer 
The  shift  number  is  updated  if  a  decision  is  made  but  the  decision 
integer  is  not  changed  until  the  path  is  complete. 


i nt  dec ide(skeleton, i ,  j , deci 3ion,shi ft_num) 
struct  model_infa  *3keleton; 
int  i; 
int  *j  ; 

long  int  decision; 
i nt  *sh i f t_num ; 

( 

i nt  next , k , I ; 
i nt  i terat i ons; 
int  f i rst_no_exec ; 
unsigned  choice; 

choice  =  (decision  >>  *shift_num)  &  0x01; 
if(choice)  choice  =  EXEC; 
else  choice  =  N0_EXEC; 

*sh i ft_num  -  =  1 ; 

sw i t  ch( cho i ce ) 

( 

case  EXEC; 

next  =  i  ♦  1  ; 

♦♦*j  ; 

/*  must  block  off  the  unchosen  branch  of  the  construct  */ 
k  -  ske l et on- >ent ry [ i ] . po i nt er ; 
f i rst_no_exec  =  k; 
switch(skeleton->entry[ i ].iype) 

( 

case  IF: 

wh i I e ( ske I et on- >ent ry [ k ] . t ype  1=  EN0_IF) 
k  »  ske I e t on- >ent ry [ k  ]  pointer; 
f or ( I  =  f i rst_no_exec ,  I  <  k;  ♦♦  I  ) 
ske I et on- >entr y [ I ] . f I ow  -  M Q_E XE C ; 
break ; 
case  ELS  I F : 

wh i  I  e ( ske I e t on- >en t r y [ k ] . t y pe  EN0_IF) 

k  *  ske I et on- >ent ry [k 1 . po i nt er ; 
for(l  *  f i rst_no_exec ;  I  <  k, 
ske I et on- >ent ry [ I ] . f I ow  =  M0_EXFC; 
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break; 
case  UHEN; 

i»hi  I  e(ske  I  eton->entry  [k] .  type  !=  ENO_CflSE) 
k  ■  ske I et on->ent ry [k] . po i nt er ; 
for( I  ■  f irst_no_exec;  I  <  k;  ++I) 
ske I eton->entry[ I ] . f low  =  NQ_EXEC; 
break; 

default:  break; 

) 

break; 

case  NO. EXEC: 

/*  jump  to  the  next  branch  using  the  pointer  element  */ 
next  *  ske I eton- >entry [ i ] . po i nt er ; 

3i»itch(skeleton->entry[  i  ]  .type) 

{ 

case  UHILE_L00P: 

♦♦next ; 
break; 

case  END_L00P : 

skeleton->entry[  i  ]  .  f  I  oui++ ; 

♦+*j  ; 

/*  need  to  guard  against  troublesome  constructs  and  ensure  that  a  */ 
/*  loop  containing  a  conditional  UFS  entry  does  not  become  an  »/ 

/*  infinite  loop  uihen  generating  paths  */ 

iterations  =  ske I et on- >ent ry [ ske I et on- >ent ry [ i  ] . po  i  nt er  ]  ua I ue ; 
i f ( i t erat i ons  >  0 ) 

i f (ske I et on- >ent ry [ i J . f I ow  ==  iterations  -  1) 
skel eton->entry[ i ] , f lorn  =  EXEC; 
i  f(skeleton->entry[  i  ]  .  flaui  ==  5)  /*  5  is  a  stringent  limit  */ 
skeleton->entry[ i ] . f low  =  EXEC; 
break; 

default:  break; 

> 

break ; 


return(next ) ; 

} 
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CALLNAflE:  PARAflETER  1 2E 
AUTHOR :  S.  Treadmell 
CREATED:  7  SEP  92 
UPOATED:  9  SEP  92 

Uill  take  a  giuen  path  through  the  model  and  add  up  all  the  critical  system 
calls  along  the  path.  This  info  is  stored  as  a  set  of  counters  and 
returned  to  the  parent  procedure. 

. . - - - V 


struct  counter_l i st  paramet er ize(skeletonJpath,path_lengthJmade) 

struct  model_info  ‘skeleton; 

int  pat h [ 3 ; 

int  path_length; 

int  mode; 

< 

int  i , k; 
int  j  =  0; 
int  laop[10]; 
int  iterations; 
int  counter_num; 

struct  counter_list  counter_set; 

counter_set . num_queued  =  0; 
counter_set . num_retr  i  eued  =  0; 
count er_set . num_sent  =  0; 
counter_set . num_read  ■  0; 
counter_set . num_msg_queued  =  0; 
counter_set . msg_retr i eued  =  0; 

for( i  *  0;  i  <  path_length;  ♦  ♦ i ) 

iterat i ons  =  1 ; 

i f (mode  *■  I ) 
for (k  =  0;  k  <  j  ;  ++k) 
iterations  *=  loop[k]; 

si#  i  t  ch(  ske  leton->entry[path[  i  ]  ]  .type) 

( 

case  LOOP:  loop[j++]  =  ske I et on- >ent ry [pat h[ i  ]]. ua I ue ;  break; 
case  F0R_L00P:  loop[j++]  =  skeleton->entry[path[  i  ]] .ualue;  break; 
case  UHILE_L00P:  loop[j++]  =  ske I et on- >entry[  pa th[  i  ]].  uo I ue ;  break; 
case  £ND_L00P:  i f  <  j  >0)  j--,  break;  /*  for  made  2 — ui  i 1 1  explain  later  */ 
case  COUNTERSET: 

counter_num  ■  ske  I  et on~>entry [path[  i  ] ] .  ua  I  ue ; 

count  er_set . num_queued  +=  skeleton->count  er_set [count  er_num ] . num_queued , 
counter_set . num_retr i eued*= 

ske I et on- >coun ter_.se t [ count  er_num] . num_ret  r i eued; 
count  er_set . num_sent  ♦»  ske I et  on- > count er_set [ count  er_num ] . num_sent ; 
count er_set . num_read+  =  ske I et on- >count er_set [count  er_num ] . num_read ; 
counter_set . num_msg_queued  += 

ske I et on- >coun ter_.se t [ count  er_num ] . num_msg_queued ; 
counter_set . msg_retr i eued  ♦= 
ske I et on- >count  er_.se t [ count  er_num] . msg_ret  r i eued ; 
break; 
case  QUEUE: 
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I f  ( i terat i on*  >  0 ) 

( 

counter_set . num_queued  ♦■( ske I et on- >entry [path[ i ] ] . ua I ue  *  iterations); 
counter_set  .  num_n\sg_queued  +=  iterations; 

) 

e  I  se 

< 

counter_set . num_queued  ♦«  ( ske I et on- >ent ry[ pat h[ i ]]. ua  I  ue  *  10); 
counter_set . num_msg_queued  10; 

) 

break; 

case  RETRIEUE; 

i f ( i terat i ons  >0) 

{ 

counter_set  .  num_ret r  ieued<-  =  (skel  et  on->ent  ry[pat  h[  i  ]]  .oalue*iterat  ions) ; 
counter_set . *sg_ret r ieued+=iterat ions; 

) 

e  I  se 

{ 

counter_set . num_ret r i eued  +*  (ske I et on- >ent ry[pat h[ i ] ] . ua I ue  *  10); 
counter_set . msg_ret  r i eued  +  =  1 0; 

) 

break; 
case  SEND: 

if  ( i terat i ons  >  0) 

counter_set . num_sent  +=  ( ske I et on- >ent rytpat h[ i ] ] . ua I ue  *  iterations); 
e  I  se 

counter_set . num_sent  +-  ( ske I e t on- >ent ry [ pat h[ i ] ] . ua I ue  *  10); 
break ; 
case  READ: 

i f  ( iterat ions  >  0) 

counter_set . num_read+*(ske let  on- >ent ryfpot  h[ i ] ] . ua I ue*  i  t  erot i ons ) ; 

e  I  se 

counter_set . num_read  ( ske I et on- >entry[ pat h[ i  ]]. ua I ue  *  10); 
break; 

default:  break ; 

) 


return(counter_set ) ; 

) 
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/* - 

CALLHAflE :  f100EL_0K 
AUTHOR:  S.  Treadwell 
CREATEO:  20  OCT  92 
UPOATEO:  12  NOU  92 

Uill  aerify  the  structure  of  the  model  to  ensure  that  it  is  prepared  for 
analysis. 

- - - - - V 


enuai  boolean  mode l_ok(ske I et on, error_f  i  I  e ) 
struct  model_info  *skeleton; 

FILE  *error_f i le; 

{ 

int  i , j ; 

int  loops  *  0; 

int  i fs  *  0; 

int  cases  *  0; 

int  waits  *  0; 

enum  boolean  ualid  -  VES; 

/*  flake  sure  the  model  begins  and  ends  with  depths  =  0  */ 
i f (ske I eton->entry [ske I et on- > I engt h  -  )]. depth  !=  0) 

{ 

ualid  =  HO; 

fpr i nt f (error_f i I e , " The  final  model  entry  is  at  the  wrong  depth\n“); 

} 

i f<skeleton->entry[0] .depth  !=  0) 

{ 

ualid  =  HO; 

fpr i nt f (error_f i I e, "The  initial  model  entry  is  at  the  wrong  depth\n”); 

} 

/*  Ensure  that  for  euery  loop  there  is  a n  end_loop  and  the  same  with  */ 

/*  case  statements  and  if  constructs  */ 

for(i  =  0;  i  <  ske I et on-> I engt h;  +  +i) 
swi tch(skeleton->entry[ i  ] . type) 

< 

case  LOOP:  ++loops;  break; 
case  F0R_L00P:  ++loops;  break; 
case  UHILE_LQGP:  ++loops;  break; 
case  EH0_L00P:  --loops;  break; 
case  IF:  ++ifs;  break; 
case  EN0_IF:  — ifs;  break; 
case  CASE:  ++cases;  break; 
case  EM0_CASE:  --cases;  break; 
case  UFS;  ♦♦waits;  break; 
case  C0UHTERSET: 

/*  make  sure  the  model  does  not  reference  a  non-existent  counter  set  */ 
i f (ske I eton- >ent ry [ i  ] . ua I ue  >=  ske I eton->num_counters) 

( 

ua I  id  -  HO; 

fpr int  f (error_f i I e, 

"Excessiue  counter_set  number  at  model  entry  Jd\n",i); 

} 

break; 

default:  break; 

} 
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i f ( I  oops  ! *  0) 

( 

valid  -  NO; 

fpr i nt f (error_f i I e , ” There  is  improper  loop  matching  in  the  mode  I  W); 

) 

i f (cases  ! *  0) 

( 

valid  =  NO; 

fpr i nt f ( error_f i I e , " There  is  improper  case  matching  in  the  mode  I  \n“ ) ; 

> 

i  f ( i fs  !«  0) 

{ 

va I  i d  *  NO; 

fpr  i  nt  f  ( error_f  i  I  e , 11  There  is  improper  i  f  /e  n  d _ i  f  matching  in  the  model\n"); 

} 

if(maits  ■■  0)  /*  ensure  that  the  task  model  includes  a  UFS  call  */ 

{ 

valid  *  NO; 

fpr i nt f (error_f i I e, " There  is  na  UFS  in  this  modeINn"); 

> 

/*  Nake  sure  there  are  no  infinite  loops  containing  no  UFS  calls  */ 
for(  i  *  0;  i  <  ske I et on- > I engt h ;  +  +  i) 

i  f  ( (ske  I  et  on->entry[  i  ]  .  type  ««  L  00P)8.t  (skeleton  -  >entry[i].value<0)) 

{ 

maits  *  0; 

for(j  ”  i  +  l;  j  <  ske I et on- > I engt h;  +*j  ) 

( 

I  f  (ske  I  et  on->ent  ry  [  j  ] .  t  ype  «»  UFS)  ++«iaits; 

I f ( (ske I et on->ent ry[ j ] . t ype  **  EN0_l00P)i& 

(ske I et on->ent ry[ j ] . po i nt er  ==  i)) 
break; 

> 

if  (maits  **  0) 

( 

valid  *  NO; 

fpr i nt f (error_f i I e , " I nf i n i t e  loop  containing  no  UFS\n"); 

} 

> 


/*  If  the  model  passes  all  tests,  valid  =  VES;  othermise,  valid  -  NO  */ 
return( va  lid); 
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/• - 

CALLNAI1E  :  CALCULATED  I  flE 
AUTHOR :  S.  Treadwell 
CREATED:  09  SEP  92 
UPDATED:  30  OCT  92 

This  procedure  takes  a  path  parameterization  and  calculates  a  louier  bound 
on  delay  for  that  path  using  system  specific  delay  data. 


i nt  ca I cu I  at e_t i me ( de I ay_dat  a , coun t  er_set ) 
struct  constant_l i st  *delay_data; 
struct  counter_list  *counter_set ; 

( 

int  sum  *  0; 
int  extra  *  0; 

i f (counter_set->num_queued>0)  sum 

(del ay_dat a- >queue_coef  f ‘count  er_set - >num_queued)-*- 

(del ay_Jat a- >queue_const ‘count  er_set ->num_msg_queued ) ; 

i f (count er_set - >num_sent >0 )  sum 

de I ay_data->queue_coe  f  f ‘count  er_set - >num_sent  +  de I ay_dat  a- >queue_const , 

i f (count er_set - >num_retr i eued >0 )  sum  ♦* 

(del ay_dat a->ret r i eue_coef  f ‘count er_set - >num_ret  r i eued ) * 

(del ay_dat a- >ret r i eue_const ‘count er_set- >msg_ret r i eued ) ; 

i f (counter_set->num_read>0)  sum  ♦» 

de I ay_data->ret r i eue_roe  f  f ‘count  er_set - >num_read‘ 
de I ay_data->retr i eue_const ; 

count er_set- >t ota l_t i me  =  sum; 

/*  Certain  critical  constructs  add  delay  to  the  frame  ouerhead  as  well  os 
/*  incurring  task  execution  delay.  It  is  critical  to  account  for  this 
/*  additional  delay  when  comparing  carious  paths.  This  extra  delay  is 
/*  not  added  into  the  " t ot a l_t i me"  parameter  but  it  i3  part  of  the  "sum" 
/*  that  i 3  returned  to  the  parent  procedure 

extra  +*  de I ay_dat a- > I H_coef f  *  counter_set->num_queued; 
i f (counter_set->num_queued  >  0) 

extra  de I ay_dat a- >RGD_m3g_coe f f  *  count er_set - >num_queued  ♦ 
de I ay_dat a- >RGD_msg_coe f f  *  count er_set - >num_msg_queued ; 
e I se  extra  ♦«  21 ; 

sum  +  *  extra; 

ret urn( sum ) ; 

} 


Appendix  E 
External  Files 


key_words.dat 

schedu I er . ma i t_f or_ schedu I e 

loop 

If 

e  I  se 
e  I  s  i  f 
cose 
uhen 

rg_ commun i cot i on . queue-message 
r g— common ication.retri eue_ message 
rg_commun i cat i on . send— message 
rg_comutun  i  cat  i  on .  read— message 
task 

»  a 

range 
package 
procedure 
beg  i  n 
end 
gt  Id 

r9 

max_xm i t_s i ze 

max— xm i t_num 

max_rcoe_s i ze 

max-TCue-num 

select 

record 

accept 


constants.dat 

queue-coefficient  45 
queue-constant  43 
retr i eue_ coe f f i c i ent  61 
retr ieue_constant  6? 
i nterrupt_hand I er_ coef f i c i ent  1 1 0 
i nterrupt_hand ler-constant  103 
RG0_*essage_coef f i c i ent  123 
RGO-msssage-constont  -12 
RGD_task_coef f i c i ent  26 
RGD— task— constant  15 
RG0_ouera I l-constant  49 
RG0_e«pty— queue-constant  70 
context—  sin  i  tch  19 
lacal_FDIR  84 
system— F0 I R  1316 
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An  Illustrative  Example 

1.  The  files  included  in  this  section  are  taken  directly  from  a  full-scale  test  of  the  AFTA 
timing  analysis  tool. 

2.  The  task  specification  file  is  task- 1  i  at .  ada. 

3.  The  source  code  for  the  application  tasks  is  found  in  the  following  files: 

app_test . ada 
sys_fd i . ada 
test-code . ada 

4.  Note  that  the  task  called  t  eat_t  is  not  intended  to  represent  actual  application  task 
code.  It  is  used  merely  for  testing  purposes  and  is  designed  to  highlight  some  of  the 
features  of  the  timing  analysis  tool  that  are  not  fully  exercised  by  the  legitimate  tasks: 
app I  1 _t ,  app 1 2_t,  and  sys_fd i_t. 

5.  The  following  files  are  intermediate  files  passed  from  the  preliminary  processing 
stage  to  the  software  and  hardware  analysis  stages: 

task-names  .  dat 
I i 3t_of_task3 . dat 
f  i  I enames . dat 

6.  The  output  of  the  analysis  is  found  in  errors  .  dat  and  resu  Its.  dat. 
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tasklist.ada 

with  config; 

with  ne_ inter  face;  use  ne_interface; 
with  gt i ds; 
with  gcids; 


—  System  task  spec f i cat i on . 


package  task_list  is 

--  specification  of  rg  tasks  in  system;  does  not  include  rg  and  io  dispatchers; 
—  they  are  special  rg4  tasks  and  are  specified  within  con  f  i  g .  i  n  i  t_c  i  d_con  f  i  g 

--  NOTE: 

There  is  no  ordering  requirement  in  list,  but  an  ordering  contention  makes 
--  the  list  easier  to  read.  The  implemented  convention  is  to  order  the  task 
--  based  on  ug,rg,  and  precedence. 
task_list  :  constant  conf i g . ta3k_l i st_r  :  =  ( 
num_tasks  =>  10, 
tasks  »>  ( 

--  tasks  only  on  ug  0 
1  *>  ( 

gcid  =>  gcids.appl l_l , 
gt id  *>  gt ids.appl 1 , 
location  =>  conf i g . one_ug , 
ug  =>  0, 

rg  *>  config. rg4, 
precedence  =>  0, 
max_xm i t_s i ze  =>  400, 
max_xmit_num  =>  5, 
max_rcue_s i ze  =>  400, 
max_rcue_num  *>  20, 
num_i or s  =>  0, 
iors  =>  ( 
others  *>  ( 

num_chains  =>  0, 
chains  =>  ( 

others  =>  (E  =  >fa I se, D=>fa I se , C= >fo I se , 8= >f a  I se , fl= >f a  I se) ) ) ) ) ) ) ; 


gcid  =>  gc i ds . app I 2_l , 
gt i d  *  >  gt i ds . app I  2 , 
location  =>  conf i g , one_ug, 
ug  =>  0, 

rg  * >  conf i g . rg4 , 
precedence  =>  4, 
max_xm i t_s i ze  =>  200, 
max_xmit_num  =>  10, 
max_rcue_s i ze  =>  200, 
max_.’cue_num  *>  20, 
num_iors  •>  0, 
iors  *>  ( 
others  *>  ( 

num_chains  =>  0, 
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chains  =>  ( 

others  =>  (E=> f a  I se , D= > f a  I se , C  =  >fa I se , B= > f a  I se , fl= > f a  I se ) ) ) ) ) , 

3  O  ( 

gcid  =>  gc  i  ds . syst em_fd i , 
gtid  =>  gt i ds . sy st em_fd i , 
location  =>  conf i g . one_vg , 

yg  O  0, 

rg  =>  config.rgl, 
precedence  *>  II, 
max_xn i t_s i ze  =  >  200, 
box_xa i t_num  »>  10, 
max_rcue_3 i ze  *>  200, 
max_rcue_num  *>  20, 
num_iors  =>  0, 
tors  =>  ( 
others  =>  ( 

num_chains  =>  0, 
chains  =>  ( 

others  =>  ( E  =  > fa  I se , D=>f a  I se, C=> f a  I se , B= >f a  I se , ft- > f a  I  se ) ) ) ) ) , 

4  =>  ( 

gcid  =>  gcids.appM_2, 
gtid  =  >  gt i ds . app  I  1  , 
location  =>  con f i g . one_og , 

yg  *>  o, 

rg  ■>  config.rg3, 
precedence  =>  3, 
max_xm i t_s i ze  =>  200, 
max_xmit_num  *>  10, 
max_rcue_s i ze  * >  200, 
max_rcue_num  1 >  20, 
num_iors  =>  0, 
iors  ->  ( 
others  »>  ( 

num_chains  =>  0, 
chains  =>  ( 

others  =>  (E* >fa I se , D*>f a  I se , C*>f a  I se , B  =  >f a  I se , A* > f a  I  se ) ) ) )  I  . 

5  =>  ( 

gcid  =>  gc i ds . app I 2_2, 
gtid  *  >  gt i ds . app I  2 , 
location  =  >  con f i g . one_ug , 

yg  ■>  0, 

rg  «>  config.rg3, 
precedence  =>  4, 
mox_x« i t_s i ze  =>  200, 
max_x* i t_nu»  =>  10, 

«ax_rcye_s i ze  200, 
max_rcye_num  =>  20, 
nui»_iors  «>  0, 
iors  »>  ( 
others  =  >  ( 

nu»_chains  =>  0, 
chains  =>  ( 

others  =>  ( E  =  > fa  I se , Ds Ma I se , C  =  > f a  I se , B= > f a  I se , A* > f a  I se  )  ) ) ) )  , 

6  »>  ( 

gcid  *>  gc i ds . app I  I _3, 
gtid  *>  gt i ds . app I  I , 
location  *>  con f i g . one_ug , 

yg  ■>  0, 

rg  =>  conf ig,rg2, 
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precedence  *>  0, 
max_xni  i  t_s  i  ze  =>  100, 
eax_xm i t_num  =>  5, 
max_rcue_s i ze  =>  200, 
max_rcue_num  ■>  20, 
num_iors  ■>  0, 
iors  *>  ( 
others  =>  ( 

num_chains  =  >  0, 
chains  *>  ( 

others  =  >  ( E- >fa I se, 0= >f a  I se , C=>f a  I se , B= > fa  I se , fl= > f a  I  se ) ) ) ) ) , 

?  *>  ( 

gc i d  *>  gc i ds , app I  2 _ 3 , 

gt i d  «>  gt i ds . app I  2 , 
location  »>  con f i g . one_og , 
ug  ->  0, 

rg  »>  con  fig. rg2 , 
precedence  - >  1, 
max_xm i t_s i ze  =>  200, 
max_xi!i  i  t_num  =>  10, 
max_rcoe_s i ze  =>  200, 
max_rcue_num  =>  20, 
nuni—iors  =  >  0, 
iars  =>  ( 
others  »>  ( 

num_chains  =>  0, 
cha ins  * >  ( 

others  *>  (E=>false,D=>false,C!=>false,B=>fal3e,fl=>fal3e))))i. 

8  •>  ( 

gc i d  ■ >  gc i ds . app I 1_1 , 
gt i d  *  >  gt i ds . app  I  I  , 
location  «>  can f i g . ane_oq , 
ug  *>  0, 

rg  « >  conf i g . rg I , 
precedence  =>  1, 

*ax_xm i t_s i ze  =  >  200, 
max_xm i t_num  =>  10, 
max_rcue_s i ze  =>  200, 
max_rcoe_num  «>  20, 
num_iars  <=>  0, 
iors  =>  ( 
others  ■>  ( 

num_chains  =>  0, 
chains  *>  ( 

others  ■>  (E  =  > f a  I se , 0  =  >f a  I se , C-> fa  I se , B  = >f a  I se , 8  =  > f a  I se ) ) ) ) ) , 

9  *>  ( 

gcid  ’>  gc i ds . app I 2_1 , 
gt  i  d  =  >  gt i ds . app I  2 , 
location  *>  con f i g . one_ug , 
og  *>  0, 

rg  *  >  con  f i g . rg  I  , 
precedence  •>  0, 

*ox_xm i t_s i ze  «>  200, 

•ax_x« i t_num  =>  10, 
max_rcwe_s i ze  =>  200, 
max_rcue_num  =>  20, 
nue_iors  =>  0, 
iors  =>  ( 
others  *>  ( 


» 


» 


4 


» 


» 


» 


i 


i 


» 


> 


» 


» 
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num_chains  =>  0, 
chains  =>  ( 

others  =  >  (E= > fa  I se , D=> fa  I se , C= > f a  I se , B= > fa  I se , > f a  I se) ) ) ) ) , 


10  ->  { 

geld  *>  gc i ds . test_l , 
gt  i d  *>  gt 1 ds . test , 
location  *>  conf  i  g . one_og, 
gg  =>  0, 

rg  = >  conf i g , rgl , 
precedence  •*>  I  , 
max_xmi  t_si  ze  =>  200, 
max_xm i t_num  =>  10, 
max_rcoe_3tze  =>  200, 
max_rcue_num  =>  20, 
num_iors  =>  0, 
iors  “>  ( 
others  *>  ( 

num_chains  =>  0, 
chains  =>  ( 

others  =  >  ( E  =  >f a  I se , D  =  >f a  I se , C  =  > f a  I se , B= >f a  I se , fl= > f a  I se) ) 5 ) ) , 


end  task_l i st ; 

--  OEC/CnS  REPLRCEriENT  HIST0RV,  Element  TRSK_L I  ST _ RDF 

—  *5  1 7— FEB- 1 992  10:11:41  FTPP  “added  iors  spec” 

--  *4  12-FEB-1992  12:18:19  SRF2234  “mooed  dispatcher  specs  within  init_cid 

—  *3  8-FEB-1992  09:52:49  FTPP  "added  io  task  assignment” 

--  *2  27-0EC-I991  09:46:35  SRF2234  "changed  precedence,  added  oppl  tasks" 

--  *1  1 3-DEC - 1 99 1  10:19:11  SRF2234  “specification  for  task  list  in  mass 

memory" 

--  DEC/CriS  REPLRCEflENT  HIST0RV,  Element  TftSK_L  I  ST_.  ADR 
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apptest.ada 


— 

Ui 

i  th 

text_i o; 

— 

UJ 

i  th 

schedu 1 er ; 

-- 

UJ 

i  t  h 

ne_i nt  er  f  ace , 

— 

w 

i  t  h 

mem_ ut i 1 s ; 

-- 

UI 

i  Ih 

conf ig; 

-- 

UI 

ith 

rg-commun i cat  ion; 

-- 

UJ 

i  t  h 

system; 

-- 

UJ 

ith 

i o_ut its; 

-- 

UJ 

ith 

t  ask_pr i or i ty ; 

-- 

UJ 

i  t  h 

gc  i  da ; 

-- 

UI 

ith 

rg_d i spatcher; 

-- 

UJ 

i  t  h 

rg_log; 

-- 

U) 

ith 

except i on_ 1 og; 

-- 

UJ 

ith 

debug— t  race ; 

-- 

UJ 

i  t  h 

unchecked— conuers i on 

package 

body  appl-test  is 

:<<<<'<<<<■ 


task  body  app  M_t  is 
my_gcid  :  conf i g . gc i d_t ; 
my_ rg  :  config.rg_ t; 

--  generics  for  printing  message 

function  fetch-long  is  neu  3yst em . f et cn_f rom-address  ( 
syst  em  .  uns  i  gned— I  onguiord ) ; 

function  fetch— word  is  new  system .  fetch-from-addrcssf 
system.unsi  gned_word ) ; 

function  fetch_byte  is  new  system . fetch_from—oddress( 

3ystem.unsi gned_byt  e ) ; 

function  byte_t0— long  is  neui  unchecked— oonuers i on( syst em . uns i yned_byte , 

system. unsigne  d_  longuiord' 

xmessage  array  ( syst em , uns i gned_ byte  range  0..60)  of  sy st em . uns i gred_ byt e , 
xerror  :  rg_ commun i cat i on . t r ansm i t_ message— st at us_t ; 

rmessage  :  array  ( syst em . uns i gned— byt e  range  0..60)  of  system ,unsigned_byte; 

rerror  :  rg_commun i cat i on . rece i ue_message_st at us_t ; 

fram_cid  :  conf i g , gc i d_t ; 

from_ug  :  ne_i nter f ace . ug i d_t ; 

size  :  natural ; 

class  :  ne_ i nt er face . c I ass_ r ; 

beg  i  n 

t ext_i o . put_l i ne{ "E I abor at i on  of  flPPLI"); 
for  i  in  xmessage  ’  range  loop 
xmessageC i )  : =  i ; 
end  loop; 

accept  startfgcid  :  conf i g . gc i d— t )  do 
my_gcid  :  =  gcid; 
end  start ; 

®y_rg  ;=  con f i g . gc i d_con f i g( my_gc i d) . rg; 
for  i  in  rg_d i spat cher . f rame_t  loop 

if  con  f  i  g  .  "  "  (my-rg ,  rg_d  i  spat  cher  .  s  I  ouiest_rg(  i  ) )  then 

rg_u ! spatcher  i O—i nt eroa I ( i )  := 
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schedu 1 er . “+"(rg_d i spatcher . io_i nt erua I ( i ) , 1 .0) ; 

end  1 f ; 
end  loop; 

rg_log.rg_log.entry(my_gcid, “flPPLI “, 

text.io.put.l  ine("flt  uifs  of  flPPLI"  8. 

conf Ig.gcld.t ' image(my.gcid)  &  “  “  8. 
conf ig . rg_t ‘ image (my_rg) ) ; 


loop 

*  for  loop:  max  ■  61 

for  i  in  xmeeeage ' range  loop 

debug_t race . debug.l og( 1 6*  f 7  f 7* , by t  e_t  o_l ong( i ) ) ; 
scheduler . ma i t.for.schedu I e; 

debug_trace.debug_log(16sfl f l*,byte_to_long( i )); 

text_io.put_l  ine("flfter  uifs  of  flPPLI"  & 
rg_log.rg_log_entry<my_gcid, "flPPLI ", 

“After  uifs  “  & 

system .  uns  i  gned_byt e '  i  mage(  i )  8  “  "  8. 
conf ig . gc i d.t ' i mage(my_gc i d)  &  “  ”  & 
con  fig. r g_t ' image ( my_r g ) )  ; 

debug_trace . debug. I og( 1 6*  f2f 2* , by t e.t  o _ I ong ( i ) ) ; 

rg.commun i cat i on . queue_message( 
my.gcid, 
my.gcid, 

x message ' address, 
natura I ( i ) , 
xerror , 

conf ig.my.ug); 

i f  rg_communicat ion. “/=”(xerror,rg_communicat ion. success)  then 
text_i o . put. I i ne( 

rg.commun ication.tr ansmi t_message_st at us.t ' i »age( xerror ) ) ; 
end  i f ; 

debug.t race . debug. I og( 1 6*f 3  f 3* , byt  e.t  o.l ong( i ) ) ; 
far  j  ii.  r-sssage ' range  loop 
rmessage(j)  :*  I6*FF*; 
end  loop; 

size  :»  natura I (rmessage ' I ast ) ; 

debug.t race . debug.l og{ 16*f^f4*,byt  e.t o.l ong( i )  ) ; 

*  message:  max  =  128 

rg.commun i cat i on . ret  r i eue_message( 
f  rom.c i d , 
my.gc id, 

rmessage ' address , 
size, 
rerror , 
from.ug, 
class) ; 

if  rg.commun i cat i on ,  (rerror , rg.commun i cat i on . success )  then 

text.io.put.l ine( 

rg.commun i cat i on . recei ue.message.s tat us.t ' i mage (rerror) ) ; 
null; 

e  I  se 

debug.t race . debug.l og( I6*f5f5*,byte_to_long( i )); 
rg_log.rg_log_entry(my_gcid, "flPPLI ”, 
text.i o . put.l i ne( "ret r i eue  :  from  "  & 

"retrieue:  from  "  & 

conf ig.gc id.t ' image( from.cid)  &  "  to  “  & 
conf  ig.gcid.t '  image(my.gcid)  &  ”  "  8. 
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i o_ut i I s . hex(rmessage ‘ address)  &  "  "  8. 
natural  1 image(size)  8.  “  to  “  8. 
ne_i nterface .vg i d_t ' image( from_og)  &  "  ”  8 
boolean' image(class. broadcast) 

ne_i  nterface  .packet_c  I  ass_t '  i  tnage(c  I  ass  .  pocket )  &  “  “  8. 
ne_i nt erf ace .exchange_c I ass_t 1 i mage(c I  ass . exchange ) ) ; 
debug_.tr ace, debug— I  og(  I 68f 6f6* jbyt e_t o_l  ong(  i ) ) ; 
rg_log.rg-log_entry<my_gci d,  “fiPPU" , 
text_io,put_l ine( 

io_ut  i  I s . hex( f etch_l ong(rmessage ' address) )  8.  ”  “  8. 
i  o_ut  f  I  s .  hex(  fetch_l  ong(  system  (message  ‘  address,  4) ) )  &  “ .  .  .  "  8 
i  o_ut  i  Is. hex  (fetch- 1  ong(  syst  em.“  +  ',(rrae33age'addre3sJ 
system,  address—i  nt  (s  i  ze-8) ) ) )  &  “  "  8. 
i o„ut i I s . hex( fetch_l ong( system .“♦"(rmessage'address, 
system . address—i nt(size -4 ))))); 

end  if; 

--  add  test  of  overrun 

if  system. i , 10)  and  conf i g . " = " (my_gc i d , gc i ds . app I ! _3 )  then 
I  oop 
null; 
end  loop; 
end  i f ; 

end  loop; 
end  loop; 
except i on 

when  NUMERIC-ERROR  => 

except  I on_l og . except i on _ I og_entry{ "RPPL1 ", "  NUMERIC-ERROR  gc i d=  "  8. 

conf ig.gcid_t ' i mage (my_gc i d) ) ; 
uihen  CONSTRAINT-ERROR  => 

except i on_ I og . except i on_ 1 og_entry( “RPPL I “ , "  CONSTRfi I NT-ERROR  g c  i  d  =  "  8 


conf ig.gci d_t ' image ( my_gc id)); 
when  PROGRRN-ERROR  => 

except ion_log.excepti on_l og_entry ( ”RPPL 1 " , 
conf i g . gc i d_ t ' i mage ( my_ gc id)); 
when  STORAGE-ERROR  => 

"  PROGRAM-ERROR 

gcid=”  8 

except i on_ 1 og. except i on _ 1 ag_entry ( “RPPL 1 " , ' 

con  f i g . gc i d_t ' i mage ( my_gc id)); 
when  TASK  1 NG-ERROR  => 

”  STORAGE-ERROR 

gcid="  8 

except  i  on_  1  og. except  ion— 1  og_entry(  ’'RPPL  1  ” , ' 
con  f i g . gc i d_t ' i mage ( my_gc id)); 
when  others  => 

*  TASK  1 NG-ERROR 

gc  i  d  = ''  & 

except ion_ log. except ion_log_entry("RPPLI ”, 
conf ig.gci d_t ‘ i mage ( my-gc id)); 

''  OTHERS  ERROR 

gcid-"  8 

end  app 1 1 _ t ; 

— >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 


task  body  appl2_t  is 
my_gcid  :  conf i g . gc i d_t ; 
my_rg  :  config.rg_t; 

--  generics  for  printing  message 

function  fetch-long  is  new  syst em , fetch_from_address( 
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system  ,  uns  i  gned_l  ongtuord) ; 

function  fetch_word  is  new  syst em . f etch_f rom_address( 
system , uns i gned_word) ; 

function  fetch_byte  is  new  system , fetch_from_address( 
syst em . uns i gned_byt e ) ; 


xmessage  :  array  (syst em . uns i gned_byte  range  Q..60)  of  syst em . uns i gned_byt e 
xerror  :  rg_commun i cat i on . t ransm i t_message_st at us_t ; 


rmessage  :  array  (syst em , uns i gned_byte  range  0..60)  of  system . uns i gned_byt e 

rerror  :  rg_com»un i cat i on . rece i ue_message_st atus_t ; 

from_cid  :  conf i g . gc i d_t ; 

from_ug  :  ne_ i nter face . ug i d_t ; 

size  :  natural; 

class  :  ne_i nter f ace . c I ass_r ; 


beg  i  n 

text_i  o  .  put_l  i  ne(  "E  I  aborat  i  on  of  RPPL2*'); 
for  i  in  xmessage ' range  loop 
xmessage( i )  : =  i ; 
end  loop; 

accept  start(gcid  :  con f i g . gc i d_t )  do 
my_gcid  :«  gcid; 
end  start; 

my_rg  :=  con f i g . gc i d_con f i g( my_gc i d ) . r g ; 
rg_l og . rg_log_ent ry(my_gc id, "flPPL2" , 

t ext_i a . put_l i ne( “fit  wfs  of  RPPL2"  & 

conf i g . gc i d_t ' i mage( my_gc i d )  &  "  ”  l 
conf i g .rg_t ' i mage(my_rg) ) ; 


I  oop 

--  *  for  loop:  max  =  61 

for  i  in  xmessage ' range  loop 
scheduler . wa i t_f  ar_st hedu 1 e ; 

text_i o . put_l i ne ( " F ft er  wfs  of  RPPL2"  8. 

conf i g . gc i d_ t ' i mage( my_gc i d)  8.  "  "  8, 
conf i g . rg_t ' i mage(my_rg) ) ; 

rg_commun i cat  Ion. send_message( 
my_gc i d, 
my_gc i d, 

xmessage 'address, 
not  ura I ( i ) , 
xerror , 

con  fig. my_ug ) ; 

if  rg_commun i cat i on ."/="( xerror , rg_commun i cat i on . success )  then 
t ext_i o . put_l i ne( 

rg_commun ication.tr ansmi t_message_st  at  us_t ' image(xerror)), 
end  if; 

for  j  in  rmessage ' range  loop 
rmessage(j)  :«  I6*FF*; 
end  loop; 

size  :»  nat ura I (rmessage ' I ast ) ; 
rg_commun i cat i on . reod_message ( 
from_c i d , 
my_gc i d , 

rmessage ' address , 
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size, 
rerror, 
from_ug, 
c I  ass) ; 

if  rg^commun i cat i on ."/*“( rerror , rg_commun i cat i on , success )  then 
text_io.put_l ine( 

r g_commun ication.recei ue_message_st  at  us_t ' image(rerror)); 

null; 
e  I  se 

rg_l og . pg_l og_entry ( my_gc id, “RPPL 2* , 
text_i o . put_l i ne( “read :  fram  “  & 

“read:  from  "  & 

conf i g . gc i d_t ‘ i mage( fram_c i d)  &  "  to  "  8. 
conf ig.gcid_t ' image(my_gcid)  8  “  ”  8 
io_ut  i  I  s  .  hex(rmessage '  address)  8,  "  8, 

natura I ' i mage( s i ze)  8  "  to  “  8 
ne_i nter f ace . ug i d_t 1 i mage( fronuug )  8  “  “  8 
boo  I ean ‘ i mage( c I  ass . broadcast )  8  “  “  8 

ne_i nt erf ace . packet_c I ass_t ' i mage (c I  ass . packet )  8  “  "  8 
ne_i nt  er f  ace . exchange_c I ass_t ‘ image(class.exchange)); 
rg_l  og  .  rg_l  og_ent  ry (my_gc  i  d ,  "RPPL 2“ , 
t  ext_i o . put_l i ne( 

i o_ut i I s . hex ( f et ch _ I ong(rmessage ' address ) )  8  "  "  8 

i o_ut i I s . hex( fet ch _ I ong(system .  *♦* (rmessage *  address ,4)) )  8  8 

i  o ut  i  1  s.hex(  f  e  >.  v.h— !  ong(  sysl  en . '  \<  aessage'address, 

syst em . address_i nt ( s i ze-8) ) ) )  8  "  “  8 
i o_ut i ls.hex(fetch_long(sy3tem. (rmessage 'address, 
system . address. int(size-l))))); 

end  i f ; 

end  loop; 
end  loop; 


except i on 

when  NUMER I C_ERRQR  => 

except  ion_  log. except  i  on_l  og_entry  (  "RPPL 2“ ,  “ 
conf i g . gc i d_t ' i mage(my_gc id)); 
when  CONSTRR I MT_ERR0R  => 

except  ion_  log. except  ion_l  og_ent  ry  ( “RPPL2 ,  “ 
conf ig . gc i d_t ' i mage(my_gc  id)); 
when  PROGRRf1_ERROR  => 

except ion_l og. except ion_l og_entry(  "RPPL2" , " 
conf i g . gc i d_t ' i mage(my_gc id)); 
when  ST0RRGE_ERR0R  => 

except ion_ log. except i on_l og_ent  ry  (  "RPPL  2" ,  " 
conf i g . gc i d_t ' i mage( my_gc id)); 
when  TASK  I NG_ERR0R  => 

except i on_l og  . except i on_l og_ent  ry( "RPPL 2" , " 
conf i g . gc i d_t ' i moge(my_gc id)); 
when  others  *> 

except  ion_ log. except i on_l og_ent ry( "RPPL 2“ , " 
conf i g , gc i d_t ' i mage(my_gc id)); 


NUflER  I  C_ERR0R  gcid="  8 
CONST RRINT_ERROR  gc.d  = 

PROGRRN.ERROR  geld'"  8 

ST0RRGE_ERR0R  geid-"  8 

TASK  I NG_ERR0R  gcid="  8 

OTHERS  ERROR  gcid="  8 


8 


end  app I 2_t ; 


■>>>>>>>: 


>  >  > 


end  appl_test; 
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sysfdi.ada 

— <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

—  ABSTRACT  package  body  system_fdi 

system_fdi  defines  the  functions  which  must  be  performed  by  the 
system  fdi  for  the  analysis  of  fault  data  from  all  ugs.  Currently, 
only  the  inter  ug  presence  test  message  reception  and  the  analysis 
of  its  timeliness  is  implemented.  In  the  euent  of  failure  of  this  te3t 
a  message  is  displayed  in  the  RG1  log. 


—  KEVUORDS  package  body  system_fdi 


—  CONTENTS  package  body  system_fdi 

—  History: 

l6-Jun-92  Carol  Babikyan 

Created  skeleton  structures  for  system_fdi  to  retrieue  messages  from 
local  fdi  on  each  UG 

--  External  Units: 

ne_interface  is  with'ed.  Prouides  ne  mapping. 

—  Except i ons : 

None  declared.  Predefined  exceptions  may  be  raised. 

—  I/O: 

message  primitiues  used 

--  UtlE  Specific: 

None 

--  ni17  Spec i f i c : 

None 

--  XOADA  Compiler  Specific: 

Refer  to  Portability  summary  of  listing 


--  ne  interface  definitions 
--  with  ne_inter face; 

--  enable  printing  directly  to  screen 
--  with  text_io; 

--  enable  wa i t_for_schedu I e  call 
--  with  scheduler; 

--  enable  access  to  clock  and  time  parameters 
--  with  c I ock_ext ens i on ;  use  c I ock_ex t ens i on ; 
--  with  calendar;  use  calendar; 

--  configuration  information 
--  with  config;  use  config; 

--  with  gcids; 

--  message  interfaces 
--  with  rg_commun i cat i on ; 

--  need  for  addresses 
--  with  system;  use  system; 
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—  with  unchecked-conversion; 

--  enable  logging  of  information  in  different  logs 
--  with  rg_log; 

—  with  fdi_ log; 

--  with  except i on_l og; 

--  with  fdi_msg; 

--  with  fdi_ globals; 


package  body  system-fdi  is 

type  ug i d_ status— r  is  record 

inter_ug_to  :  ca I endar . t i me ; 

I ast_ i nt er_ vg_ t i me  :  c  I  ock_ ext ensi on . system_t i ck_ t ; 

cur_ i nter_ ug_ t i me  :  c  I  ock_ext ens i on . system_t i ck_t ; 

end  record; 

ugid_ status  :  array  (ne_i nt er face . ug i d_t )  of  ug i d_3tat us_r ; 
initial— time  :  c  I  ock_ ext ensi on . system-t i ck_t  :=  0; 


task  body  3ystem_ fdi_t  is 
my_ gc i d  i  conf i g . gc i d_ t ; 
my_rg  ;  config.rg— t; 


xmessage  ;  f d i_msg . message— r; 

xstatus  ;  rg_commun i cat i on . transmi t_message_3tatu3_t ; 


rmessage  :  fd i_msg . message_r ; 

rstatus  rg_cammun i cat i an . rece i ve_message_st at us_t ; 


f  rom_ gc i d 
from— ug  : 
size  : 
class  : 
syndrome 


conf i g . gc i d_ t ; 
ne_ interface. ugi d_t ; 
natura I ; 

ne_ i nt  er  face . c I ass_r ; 

fd i_g I oba I s . syndrome— r ; 


presence  test  buffer  (syndrome  info  is  saved  for  syndrome  anolysis) 
type  pt_ buffer— r  is  record 

from— ug  :  ne_ i nter f ace . ug i d_t ; 
syndrome  :  f d i_g I oba I s . syndrome— r ; 
class  :  ne_i nt er face . c I ass_r ; 

end  record; 


max— pt_entr i es  :  constant  :=  80; 

type  pt_ entry— t  is  range  0 . . max_pt_ent r i es ; 

num_pt_entr i es  :  pt_entry_t; 

pt-buffer  :  array  (pt_entry_t  range  I . .max_pt_entr ies)  of  pt_buffer_r; 

function  ticks— to_int  is  new  unchecked-conversion 

(c  I  ock_  ext  ens  i  on  .  system— t  i  ck_  t  , system.unsi  gned_  I  cngword )  ; 

function  i n t _ to_ ticks  is  new  unchecked-conversion 

( system . un s i gned_l on gw or d , c I ock— ext  ension.syst  em_t i c  k _ t ) , 


Compute— UG-T i meout  computes  the  maximum  time  between  receipt  of  inter-UG- 
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presence  test  messages  for  each  virtual  group  in  the  configuration. 

The  timeout  period  is  computed  as  3  times  the  frame  time  of  the  F D I R  task 
on  the  tested  uirtual  group.  Since  FDI  task  executes  as  a  rate  group 
task  this  is  essentially  3  *  the  minor  frame  duration. 

Uhen  using  the  NE  simulator  this  time  must  be  exaggerated  because  the 
system  timestamps  are  accurate  and,  of  course,  the  ne  sim  is  not! 


Procedure  Compute_UG_T i meout  is 


frame-t ime.int  : 
to_int  : 

to_scal e_factor  : 
t  o_t  I  ck  : 


system . uns i gned_l ongword; 
system. unsi gned_i ongword; 
system , uns i gned_l ongword  : =  3; 
clock_extension. system_t ick_t ; 


begin 

for  i  in  ne_interface. vgid_t  loop 

if  conf i g . vg i d_conf i g( i ). redundancy  /■  conf i g . redundancy-1 eue l_t ( 0 )  then 

frame_t i me_i nt  :=  t i cks_t o_i nt (c I ock_ext ens i on . rep_t o_t i ck 
(conf i g . ug i d_conf ig(i). frame)); 
to_int  :=  to_sca 1 e_factor  *  frame_t i me_i nt ; 
to_tick  : »  int_to_t icks(to_int) ; 


og i d_st atus( i ) .  i nt  er_ug_t o  ; ■  cl ock_ext ens i on . sy3t i ck_t  o_t i me( t  o_t i ck ) ; 

vgi d_status( i ) . I ast_i nter_ug_t i me  :=  i n i t i a l_t i me ; 
vgi d_st at us( i ) . cur_i nter_vg_t i me  :=  in i t i a l_t i me ; 
end  i f ; 
end  loop; 
end; 


Read_al l_messages  reads  all  messages  and  updates  the  information  relevant 
to  the  specific  type  of  message. 

!nter_vg_presence_test  messages  are  used  for  2  purposes: 

1)  the  syndrome  associated  uiith  the  message  is  used  in  syndrome 
analysis 

2)  The  time  of  receipt  is  used  to  determine  the  next  expected 
arr i ua I  of  an  i nt er_vg_pr esence_t es t  message.  Failure  to 
receive  this  message  within  the  allotted  time  implies  the 
UG  i s  f au 1 1  y . 

Syndrome_exchange  message  contains  the  syndrome  data  for  a  single 
member  of  the  system  FDI  UG .  The  receipt  of  source  congruent  messages 
from  each  member  of  the  system  fdi  UG  is  necessary  to  perform 
syndrome  analysis.  Should  one  member  of  the  system  fdi  UG  be  faulty 
its  data  may  be  corrupted.  Consequently,  if  a  source  congruent 
message  is  received  from  the  system  fdi  UG,  it  will  be  assumed  that 
that  message  is  a  syndrome  exchange  message. 


Procedure  Read_ol l_messages  is 


procedure  extract_inter_vg_pt_info( i  :  in  out  pt_entry_t)  is 

begin 

i  :=  i  ♦  t  ; 
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pt_buf fer( i ) . from_ug  :■  from_ug; 
pt_buf fer( i ) . syndrome  syndrome; 
pt_buf fer( i ) . c I  ass  :=  class; 

Update  time  of  receipt  of  current  i nt er_ug_presence_t est 
message 

ug i d_stat us( from_ug) . cur_i nt er_og_t i me  :=  syndrome . st amp; 

end; 


procedure  extract_syndrome_exch_i nfo  is 
beg  I  n 

null; 

end; 


procedure  check_f or_m i ss i ng_syndrome_exch  is 
beg  i  n 

null; 

if  from_ug  =  my_ug  then 
case  class  is 
when  A  => 
when  6  -> 
when  C  «> 
when  0  =  > 
when  E  => 

when  others  =>  software  error!!!! 
end; 
end  i f ; 
end; 


beg  i  n 

num_pt_ent r i es  :■  0; 

*  basic  loop:  max  *  12 
read_l oop : 

I  oop 

Receiue  the  inter-UG  presence  test  message  from  local  FDI 
size  :■  rmessage 1 s  i  ze/8 ; 
rg_commun icat ion.retri eue_message< 
from_gc i d, 
my_gc id, 

rmessage 'address, 
size, 
rstatus, 
from_ug, 
c I  ass, 
syndrome ) ; 
case  rstatus  is 

when  rg_commun i cat i on . success  => 
case  rmessage . message_type  is 
when  f d i_msg . I NTER_UG_PT  => 

extract_int  er_ug_pt _i n  fo(num_pt _ent r i es ) ; 
when  fdi_msg.  SVHDR0I1E_EXCH  *> 

extract_syndrome_exch_info; 
when  others  *>  check_for_m i ss i ng_syndrome_exch ; 
end  case; 

when  rg_commun i cat i on . no_message  => 
exit  read_loop; 
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•hen  others  «> 

text_io.pu*_l ine( 

rg_commun [ cat i on . rece i ve_message_st at  us_t ' image(rstatua)j, 
exit  read_loop; 

end  case; 

end  loop  read_loop; 


end; 


This  procedure  checks  the  timeouts  of  all  active  UGs.  If  the  time  has 
elapsed  beyond  the  time  expected  for  receipt  of  a  message,  the  UG  mill 
be  diagnosed  as  faulty. 


Procedure  Check_i nter_ug_t imeouts  is 

delta_sys_t icks  :  clock_extension.system_t ick_t ; 
begin 

for  I  in  ne_interface. vgid_t  loop 

If  conf ig . vg I d.conf i g( i ). redundancy  /»  conf i g . redundancy_l eve l_t (0 )  then 

rg_l og.rg_log_entry (my_gc id,  "SVSTEf1_FDI  ” , 
ne_i nt er face . vg i d_t ' image(  i )  & 

clock_extension.sy3tem_t i ck _ t ' image 

(vg id_status( i ) . Iast_i nt er_vg_t i me)  &  "  "  1 
c I ock_extens ion . syst em_t i ck_t ' i mage 

(vgid_status( i ) . cur_inter_vg_t ime)) ; 


—  Check  the  next_i nter_vg_t i me  to  determine  if  it  has  expired 
delta_sys_t icks  : ■ 

clock_ext ension . d i f f_sys_t i cks(  vg i d_status( i ) . cur_inter_vg_t i me, 

vg i d_st at us(i).last_int er_ug_t ime); 
if  c I ock_ext ens i on . sy st i ck_t o_t i me(de I t a_sys_t i cks )  > 

vgid_status( i ) . inter_vg_to  then 
if  vgid_status( i ) . Iast_inter_vg_t ime  /-  initial_time  then 
f  d i _ I og . fdi_log_entry("SVSTEH_FDI ", 

“UG  “  &  ne_interface.vgid_t ' image( i )  & 
failed  Inter-UG  timeout:  ”  8. 
clock_extension.system_t ick_t ' image 

(vg i d_status(  i ) .  Iast_inter_vg_t  i me)  &  '  "  8. 
clock_extension.system_t ick_t ' image 

(vgid_status( i ) .cur_inter_vg_t ime)) ; 


end  i f ; 
end  I f ; 

vg id-status ( i ) . I ast_inter_vg_t ime  : *  vg i d_st atus( i ) . cur_i nt er_gq_t ime; 
end  if; 
end  loop; 
end; 


Procedure  flna I yze-syndrome  is 

This  procedure  analyzes  the  syndrome  matrix  received  as  a  result  of  last 
frame's  syndrome  exchange.  The  syndrome  matrix  contains  the  syndrome 
—  patterns  perceived  by  each  member  of  the  system  fdi  UG  for  each  UG  from 
•horn  it  received  an  i nter_vg_presence_test  message. 
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begin 

null; 

end  flna I yze_syndrome; 


Procedure  Exchange—syndroae  is 

—  This  procedure  performs  a  series  of  source  congruent  exchanges  to 

distribute  the  syndrome  data  for  those  inter  UG  presence  test  Messages 
receiued  this  iteration.  Upon  couplet  ion  each  Member  of  the  system  FDI  UG 
alii  haue  congruent  copies  of  the  syndrooe  bytes. 


begin 
nul  I ; 

end  exchange_syndrone; 


beg  i  n 

t ext_i o . put_l i ne( "E I aborat i on  of  SVSTEH_FDI * ) ; 
accept  start(gcid  :  con f i g. gc i d_t )  do 
my.gcid  :*  gcid; 
end  start; 

my_rg  ;*  conf i g . gc i d_conf i g< my_gc i d ) . rg; 
rg_ I og .  rg_l  og_ent  ry  (my_gc  id,  "SVSTEf1_FQ  I  “  , 

conf  i  g  .  gc  i  d_t '  i  moge(my_gc  i  d)  fc  "  '  8. 
conf ig.rg_t ' i mage(my-rg) ) ; 

--  Compute  timeout  times  for  each  uirtual  group  in  the  configuration 
coapute_ug_t i meout ; 

I  oop 


schedu I er . wo i t_f  or_schedu I e ; 

—  Read  ony  messages  sent  to  System  FDI 
Read_al I —messages; 

rg_l  og  .  rg_  I  og_ ent  ry(my_gc  id,  "SVSTEf1_FD  I  "  , 

pt_entry_t ' image(num_pt_entries)  &  "  messages  read  “); 

Examine  inter-ug  presence  test  for  timeouts 
Check_inter_ug_t imeouts; 

—  Rnalyze  syndrome  receiued  this  frame 
Rna I yze_syndrome ; 

—  Exchange  syndrome  for  next  frame 
Exchange-syndrome ; 

end  loop; 
except  ion 

•hen  NUIIERIC-ERROR  ■> 

except i on_l og . except i on_log_entry("SVSTfcf1_FD I " , "  NUMER I C-ERROR  " ) ; 
•hen  CONSTRAINT-ERROR  ■> 
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except  i  on_l  og  .  except  i  on_l  og_ent ry ( "SVSTEf1_FQ  I " , "  CQHSTRfl  I  NT_ERR0R” ) ; 

•hen  PR0GRRf1_ERR0R  -> 

except  ion_  log.  except  i  on_l  og.ent  ry  ( "  SVSTE  fl _ F  □  I  “  ,  "  PR0GRftt1_ERRQR“ ) ; 

•hen  STORRGE_ERROR  *> 

except i on_i og . except i on_l og_entry < “ SVSTEfl _ FD 1“ , "  ST0RRGE_ERR0R" ) ; 

•hen  lKSIClNG_ERROfl  -> 

except i on_l og . except i on_l og_ent ry ( "SVSTE I1_FD I " , "  TASK  I NG_ERRQR" ) ; 

•hen  others  *> 

except i cn_l og . except i on_l og_ent ry ( "SVSTEn_FD I” , "  OTHERS  ERROR” ) ; 
end  syate«_fdi_t ; 

— >>>>>>>>>>>>>>>>  ✓>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

end  syste»_i'di; 
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testcode.ada 

with  f i rst— package; 
with  second— package ; 
pai -age  body  test-code  is 
task  body  test— t  is 
begin 

I  oop 

f i rst_ package . second; 
second-package . first; 
end  loop; 
end  test_t; 
end  test-code; 


first_package.ada 

package  body  f i rst_ package  is 

procedure  first  is 

i  :  natura I ; 

size  :  nat ura I ; 

condition  :  natural; 

a  :  natura I ; 

b  :  natura I ; 

c  :  natura I ; 

d  :  natural ; 

e  :  naturol; 

beg  i  n 

for  i  in  I , , 2  I oop 

rg_  coitnun  icat  ion.retri  eue_ message  ( a ,  b, c  ,  190,  d,  e ) ; 
end  loop; 

--  *  white  loop:  max  =  2 
while  condition  <  10  loop 

rg_ commun icat ion. queue-message  (a,b,c,50,d,e); 
scheduler. wai t_ f  or_3chedu I e ; 
end  loop; 
i  f  cond i t i on  >  20 

--  *  message:  max  =  50 

rg_ commun  icat  ion.  queue-message  (a^.CjSize.d.e); 

e  I  se 

--  *  message:  max  =  100 

rg_ commun icat ion. queue-message  (o,b,c,size,d,e); 

end  if; 
end  first; 
procedure  second  is 
i  :  nat  ura I ; 
temperature  :  natural; 
beg  i  n 

--  *  for  I oop :  max  «  1 t 
for  i  in  I . . natura I  I oop 
f i rst ; 

schedu I er . wo i t_ f  or_ schedu I e ; 
if  i  >6  f  i  rst ; 
end  i f ; 
end  loop; 
end  second; 
end  f i rst-package ; 
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second_package.ada 

package  body  second_package  is 
procedure  first  is 
a  :  natural; 
b  :  natura i ; 
c  :  natural ; 
d  :  naturai; 
e  :  natural; 
begin 

rg_conmuni cat  i  on  .  send_inessage(a ,  b,  c,  200,  d,  e) ; 
end  first; 
end  second_package; 
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tasknames.d.-t 

app I l_t 
oppl2_t 
ayatea_fd i_t 
teat_t 
done 


list_of_tasks.dat 

app I 1_t  0  1  400  5  100  20 
app I 2_t  0  1  200  10  200  20 
aystea_fdi_t  0  1  200  10  200  20 
app 1 1_t  0  3  200  10  200  20 

app I 2_t  0  3  200  10  200  20 

app I 1_t  0  2  100  5  200  20 

app I 2_t  0  2  200  10  200  20 

app I 1_t  0  1  200  10  200  20 

app I 2_t  0  1  200  10  200  20 

teat_t  0  1  200  10  200  20 


filenames.dat 

app I 1_t 

USER :  t TREROUELL . RFTfi]RPP_TEST , ROR;  3 
app I 2_t 

USER : [TREROUELL . RFTfl]RPP_TEST . ROR ;  3 
ayate«_fdi_t 

USER: [TREROUELL. RFTR]SVS_FD1 .ROR; 12 
teat_t 

USER :  [ TRERDUELL . RFTR ] TEST_C00E . ROR ;  6 
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results.dat 

All  results  are  giuen  in  terns  of  microseconds. 
The  allotted  minor  frame  time  is  10000. 

RESULTS  for  UG*0 

TASK:  appl t_t  RATE  GROUP:  4 
UQRST  CASE  PATH:  number  of  packets  queued:  7 
number  of  messages  queued:  I 
number  of  packets  retrieved:  3 
number  of  messages  retrieved:  1 
number  of  packets  sent:  0 
number  of  packets  read:  0 
minimal  delay:  608 
TASK:  appl2_t  RATE  GROUP:  4 
UORST  CASE  PATH:  number  of  packets  queued:  0 
number  of  messages  queued:  0 
number  of  packets  retrieved:  0 
number  of  messages  retrieved:  0 
number  of  packets  sent:  4 
number  of  packets  read:  4 
minimal  delay:  534 
TASK:  system_fd i_t  RATE  GROUP:  4 
UORST  CASE  PATH:  number  of  packets  queued:  0 
number  of  messages  queued:  0 
number  of  packets  retrieved'  48 
number  of  messages  retrieved:  12 
number  of  packets  sent:  0 
number  of  packets  read:  0 
minimal  delay:  3732 
TASK:  app I 1_t  RATE  GROUP:  3 
UORST  CASE  PATH:  number  of  packets  queued:  4 
number  of  messages  queued:  1 
number  of  packets  retrieved:  3 
number  of  messages  retrieved:  1 
number  of  packets  sent:  0 
number  of  packets  read:  0 
minimal  delay:  473 
TASK:  app I 2_t  RATE  GROUP:  3 
UORST  CASE  PATH:  number  of  packets  queued:  0 
number  of  messages  queued:  0 
number  of  packets  retr’-.ved:  0 
number  of  messages  retrieved:  0 
number  of  packets  sent:  4 
number  of  packets  read:  4 
minimal  delay:  514 
TASK:  app 1 1 _t  RATE  GROUP:  2 
UORST  CASE  PATH:  number  of  packet?  queued:  7 
number  of  messages  queued:  I 
number  of  packets  retrieved:  3 
number  of  messages  retrieved:  I 
number  of  pockets  sent:  0 
number  of  packets  reod:  0 
minimal  delay:  608 
TASK:  app I 2_t  RATE  GROUP:  2 
UORST  CASE  PATH:  number  of  packets  queued:  0 
number  of  messages  queued:  0 
number  of  packets  retrieved:  0 
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number  of  messages  retrieued:  0 
number  of  packets  sent:  4 

number  of  packets  read:  4 

minimal  delay:  534 
TASK:  appl l_t  RATE  GROUP:  I 
UGRST  CASE  PATH:  number  of  packets  queued:  4 
number  of  messages  queued:  1 

number  of  packets  retrieued:  3 

number  of  messages  retrieued:  1 
number  of  packets  sent:  0 

number  of  packets  read:  0 

minimal  delay:  473 
TASK:  app I 2_t  RATE  GROUP:  I 
UORST  CASE  PATH:  number  of  packets  queued:  0 
number  of  messages  queued:  0 
number  of  packets  retrieued:  0 
number  of  messages  retrieued:  0 
number  of  packets  sent:  4 

number  of  packets  read:  4 

minimal  delay:  534 
TASK:  test_t  RATE  GROUP:  1 
UORST  CRSE  PATH:  number  of  packets  queued:  6 
number  of  messages  queued:  4 
number  of  pockets  retrieued:  16 
number  of  messages  retrieved:  4 


number 

of  packet 

s  sent  : 

4 

number 

of  packets  read: 

0 

minimal 

delay:  1 

909 

RATE  GROUP 

TOTALS  FOR  APPLICATION 

TASKS 

rate  group 

1  : 

2916 

rote  group 

2: 

1142 

rote  group 

3: 

1007 

rate  group 

4: 

4874 

0UERHEA0  TOTALS 

minor  frame 

0 

7041 

minor  frame 

1 

2043 

minor  frame 

2 

2992 

minor  frame 

3 

2081 

minor  frame 

4 

4678 

minor  frame 

5 

2043 

• 

minor  frame 

6 

2992 

minor  frame 

7 

2138 

HIN0R  FRAME 

OUERHEAD 

RG4 

RG3 

RG2 

RG1 

0 

7041 

2959 

0 

0 

0 

1 

2043 

4874 

1007 

1142 

934 

2 

2992 

4874 

1007 

0 

1127 

3 

2081 

4874 

0 

0 

855 

4 

4678 

4874 

448 

0 

0 

5 

2043 

4874 

559 

1142 

0 

6 

2992 

4874 

1007 

0 

0 

7 

2138 

4874 

0 

0 

0 

RG4  did  not  satisfy  its  boundary  in  frame  0. 
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errors.dat 

The  matching  between  tasks  and  filenames  is... 

0  applt-t  USER : [ TREAOUELL . RF TR]APP_TEST . ADR; 3 

1  app I 2_t  USER : [TRERDUEIL . RFTfl]APP_TEST . ADA;  3 

2  system_fdi_t  USER : [TREflOUELL . AFTA]SVS_FO I . RDft; 1 2 

3  test_t  USER: [TREADUELL . RFTR]TEST_C00E . ADA; 6 


SOFTURRE  RNRLVSIS  FOR  appl1_t 

The  packages  found  are.,. none 
Now  processing  task  applt_t 


Assuming 

default  size 

for 

queue. 

.measoge 

T ask  tlode  1  .  . 

0  Type 

1 

Ua 1 ue : 

-3 

Depth 

0 

Po inter; 

7 

1  Type 

55 

Ualue: 

6! 

Depth 

1 

Po inter: 

6 

2  Type 

0 

Ua 1 ue : 

-2 

Depth 

2 

Po inter: 

-2 

3  Type 

7 
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SOFTURRE  RNRLVSIS  FOR  appl2_t 

The  packages  found  are... none 
Now  processing  task  appl2_t 

Unexpected  task  name  --  found:  app I  1 _ t  expected:  app!2_t 
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SOFTURRE  ANRLVS I S  FOR  syst em_fd i_t 

The  packages  found  are... none 

Noui  processing  task  system_fdi_t 

Assuming  default  size  for  retr i eue_message 

Procedure  comput e_ vg_ t i meout  found  in  USER :[ TRERDUELL . RFTR ]SVS_F0 I  RDR ; 1 2 
Type;  55  Ualue;  -2  Depth:  0  Pointer:  2 

Type:  51  Ualue:  -2  Depth;  0  Pointer:  0 

Procedure  read_a I f -messages  found  in  USER : [ TRERDUELL . AFTA]SVS_FD 1 . RDR; I  2 

Type:  51  Ualue:  0  Depth:  0  Pointer;  -2 

Ctr  0:  Queued  0  Rtrud  48  Sent  0  Read  0 

Procedure  extract _i nt er_ug_pt_i n f o  found  in  USER : [ TREADUELL . RFTA]SVS— FD I . RDR ; 1 2 
Procedure  extract_syndrome_exch_i nfo  found  in  USER :[ TRERDUELL . RF Tfl ]SVS_F0 I  RDfl;!2 
Procedure  check_f or_m i ss i ng_syndrome_exch  found  in 
USER : [TRERDUELL . RFTR]SVS_FD I .RDR; 12 

Procedure  eheck—int er_ vg_t i meout s  found  in  USER :[ TRERDUELL . RFTR ]SVS_FD I  RDR, 12 
Type:  55  Ualue:  -2  Depth:  0  Pointer:  2 

Type:  51  Ualue:  -2  Depth:  0  Pointer:  0 

Procedure  anal yze_syndrome  found  in  USER: [TRERDUELL . AFTfl]SVS_FD 1 . RDR; 1 2 
Procedure  exchange-syndrome  found  in  USER :{ TRERDUELL . RFTR ]SVS_F0 I  RDR; 12 
Task  node  I . . . 
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Queued:  0  Retrieved:  48  Sent:  0  Read:  0 


SOFTUflRE  RNALVSIS  FOR  appfl-t 

The  packages  found  are  ...  none 
Naui  processing  task  appl1_t 
Assuming  default  size  for  queue-message 
Task  Mode  I . .  . 
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SOFTUARE  ANALYSIS  FOR  oppl2_t 

The  packages  found  are... none 
Non)  processing  task  a ppl2_t 

Unexpected  task  name  --  found:  appi1_t  expected:  appl2_t 
Assuming  default  size  for  queue-message 
Assuming  default  size  for  send_message 
Assuming  default  size  for  read-message 


Task  Hodel 

0  Type: 

1 

Ua 1 ue : 

-3 

Depth : 

0 

Po i nter : 

? 

1  Type: 

55 

Ua  1  ue : 

61 

Depth : 

l 

Pointer: 

6 

2  Type: 

0 

Ua 1 ue : 

-2 

Depth : 

2 

Painter: 

-2 

3  Type: 

9 

Ua  1  ue : 

4 

Oepth : 

2 

Pa  inter: 

-2 

1  Type: 

IQ 

Ua 1 ue : 

4 

Depth : 

2 

Po inter: 

-2 

5  Type: 

51 

Ua 1 ue : 

-2 

Depth : 

1 

Po inter: 

1 

6  Type: 

51 

Ua 1 ue : 

-2 

Oepth : 

0 

Po inter: 

0 

PATH:  Q 

1 

2 

PATH:  3 

4 

5  1  2 

PATH:  3 

•1 

5  6  0 

1 

2 

The  worst  path  is  charact er i zed  by... 

Queued:  0  Retrieued:  0  Sent:  4  Read:  4 
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The  packages  found  are... none 
Now  processing  task  appll_t 
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SOFTUARE  RNALVS I S  FOR  appl2_t 

The  packages  found  are... none 
Not#  processing  task  app)2_t 

Unexpected  task  name  —  found:  appl1_t  expected:  opp!2_t 
Assuming  default  size  for  queue-message 
Assuming  default  size  for  send_message 
Assuming  default  size  for  read-message 


Task  flodel 
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The  packages  found  are... none 
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SOFTWARE  ANALVSIS  FOR  appl2_t 

The  packages  found  are... none 
Now  processing  task  opp)2_t 

Unexpected  task  name  —  found:  appl1_t  expected:  appl2_t 
Assuming  default  size  for  queue-message 
Assuming  default  size  for  send_message 
Assuming  default  size  for  read_message 
Task  Node  I . . . 


0  Type: 

1 

Ual ue : 

-3 

Depth : 

0 

Po inter: 

7 

1  Type: 

55 

Ua 1 ue : 

61 

Depth : 

1 

Po inter: 

6 

2  Type: 

0 

Ualue: 

-2 

Depth : 

2 

Pointer: 

-2 

3  Type: 

9 

Ualue: 

1 

Depth : 

2 

Po inter: 

-2 

4  Type: 

10 

Ualue; 

1 

Depth: 

2 

Po inter: 

-2 

5  Type: 

51 

Ualue : 

-2 

Oepth : 

1 

Po i nter : 

1 

6  Type: 

51 

Ualue: 

-2 

Depth : 

0 

Pointer: 

0 

PATH:  0 

1 

2 

PATH:  3 

1 

5  1  2 

PATH:  3 

1 

5  6  0 

1 

2 

The  worst  path  is  charact er i zed  by... 
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SOFTWARE  ANALVSIS  FOR  test_t 

The  packages  found  are... 
f irst_package 
second_package 

Now  processing  package  secand_package 
Now  processing  package  f i r st_package 
Now  processing  task  test_t 
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A  Checklist  for  Adding  Critical  Constructs 

1.  Designate  a  constant  name  that  is  to  be  used  to  refer  to  the  new  construct  and  add  the 
constant  definition  to  the  list  in  HEADER. H 

EX:  define  NEU_CONSTRUCT  28 

2.  Add  a  new  integer  parameter  to  the  count  er_set  structure  definition  in 
HEADER.H. 

EX:  int  ne»_construct ; 

3.  Add  the  new  delay  parameter  to  the  const  ant_l  i  st  structure  definition  listed  in 
HEADER.H. 

EX:  int  ne»_construct_const ; 

4.  Add  the  new  construct  to  the  end  of  the  list  in  “key_words.dat.” 

5.  Add  the  delay  constant  corresponding  to  the  new  construct  to  “constants.dat.” 

EX:  ne«_construct_de  I  ay  33 

6.  Add  the  new  delay  parameter  to  the  read_l  i  st  procedure  for  reading  in  delay 
constants. 

EX:  f  scanf ( I i 3t _ f i I e , ”*3  Xd\n”, dummy_3t r i ng,&dummy_int); 

delay_data->neui_construct_const  *  dum»y_int; 

7.  Add  the  new  parameter  to  the  initialization  lists  found  in  toak-parse. 
generate_paths,  and  f  i  nd_u)orst_path. 

EX:  f  i  na  l_count  er  .  ne«/_con3t  ruct  =  0; 

8.  Add  the  new  construct  to  the  switch  statement  in  the  search  procedure.  If  it  is  a 

subprogram  call,  group  it  with  the  message  passing  calls  and  use  the  ua  I  i  d_ca  I  I 

procedure  to  verify  any  occurrence  of  the  new  construct.  The  code  should  look 

something  like  this... 

EX:  case  NEU.CONSTRUCT: 

i  f (ua I i d_ca I  I < t h i 3 _ I ine->entry[i].noine, 

search_l i st - >ent ry [ j ] . name)  »»  VES) 

< 

ske I et on- >ent ry [ske I et on-> I ength] . t ype  *  NEU_CONSTRUCT ; 
ske I eton- >ent ry [ske I et on-> I engt h] . ua I ue  »  UNDEFINED; 

If  ( f I ags->ctr_act i ue)  ♦♦ske I et on-> I engt h; 

1 

break ; 

9.  Add  the  new  construct  to  the  summation  in  check_ct  rs. 

10.  Add  the  new  construct  to  the  switch  statement  in  parameterize. 

EX:  case  NEU_C0NSTRUCT : 

♦♦count er_set . ne®_construct ; 
break; 
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11.  Add  the  new  construct  to  the  calculations  in  ca  I  cu  I  at  e_t  i  me. 

EX’su®  +  *  de  I  ay_data-  >neuj_const.ruct._con3t*counter_3et  .  neiu_const  ruct 

12.  Add  the  new  construct  to  the  parameter  listing  in  utr  i  t  e_f  i  le. 

EX:  fprinlf(autfile,  “  neui  construct  instances:  Xd\n”, 
ug[ i ] . task! j ] . count er_set . new_construct ) ; 


[AFTA91] 

[B0087] 

[CLAS92] 

[CLAS°3] 

[DOL82] 

[DOL84] 

[HAR91] 

[LAM82] 

[PARK90J 

[PUS89J 
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